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[57] ABSTRACT 

A central depository for secure storage and rapid re- 
trieval of important documents and information, such as 
living wills, durable powers of attorney, testamentary 
wills, authorization for organ donation, authorization of 
bone marrow donation, and insurance information. The 
depository includes a data storage facility having a 
computer and Write Once, Read Many (WORM) drive 
CD-ROM player connected to an optical scanner. The 
documents are scanned by the optica] scanner and 
stored on the CD-ROM player. Other information is 
entered into data storage facilities connected to the 
computer. Requests for information can be received by 
the depository from remote locations by data transmis- 
sion devices, such as telephone, facsimile, postal ser- 
vice, or electronic mail. The system also provides a 
procedure for updating the information and documents 
as legislation regarding the stored information and doc- 
uments changes. Also, the system monitors for changes 
in residence which may affect the information and doc- 
uments. 

27 Claims, 6 Drawing Sheets 
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powers of attorney and collateral data bases of testa- 
SYSTEM FOR ADMINISTERING A CENTRAL men tary wills, insurance information and organ and 
DEPOSITORY FOR LIVING WILLS AND OTHER ^ne marrow donors. 

ASSOCIATED INFORMATION The presem inventio „ provides , data processing 

BACKGROUND OF THE INVENTION 5 S f ,em * d ° cumen " as wel1 as information 

about the individual that may be necessary in times of 

1. Field of the Invention: crises. 

The present invention relates to the field of centra! present invention provides a system that can 

depositories for living .wills, testamentary wills, durable e these documents ^ provides infonnation to 

powers of attorney, insurance information and organ ,u „ - r „ tKtt <u„ i™i 

donor data banks. y documents for accuracy and legal require- 

2. Statement of the Problem: m ^ 

In times of emergencies, there is often an urgent need The P resent inventlon provides a system that can 

for immediate access to important documents. For in- periodically review for legislative updates, 

stance, the general public is becoming aware of their 15 present invention provides a system that can 

right to refuse medical treatment or terminate life sup- periodically review and verify for changes of address 

port systems, in the event of imminent death or perma- and situations. 

nent unconsciousness. However, this right needs to be The present invention provides a system that can 

expressed in advance, through documents such as a process requests for stored information and retrieve 

living will and durable power of attorney. 20 such information f or authorized requestors. 

These documents are typically, if at all, created, exe- xh e present invention provides a system that can 

cuted and filed in a haphazard manner, with little regard tnasmit such reque sted information directly to the 

to their accuracy or uniformity, or to ease of access, reauestor 

security or to updating the documents for legal suffi- 1_ . ^. . . . . . . . 

ciency in case of legislative changes or changes of resi- 25 . These and other solutions are provided by the present 
dential jurisdiction. The documents are created in an inv «*°n a / w >" become evident from the ensuing de- 
individual manner and then filed away where they can * C "P"™ of the invention taken m conjunction with the 
be lost or destroyed. At best the documents are stored in drawings. 

a safety deposit box with limited access thereto. Gener- SUMMARY OF THE INVENTION 

ally, relatively few people provide for ready access to 30 

these documents, or other documents, such as living The present invention provides a central depository 
wills, testamentary wills and/or organ and blood mar- for secure storage and rapid retrieval of important doc- 
row donor forms, at the times of crisis when these docu- uments and information. This includes such items as 
ments are most needed. living wills, durable powers of attorney, testamentary 
This is particularly true in today's mobile society 35 wills, authorization for organ donation, authorization of 
where catastrophic accidents or illnesses can occur in bone marrow donation, and insurance information, 
locations away from home. An individual can be in- Qne preferred embodiment of the present invention 
volyed in a catastrophic accident or illness in a location includes a data sl facflit havin a com uter and 

n'lw A 0 ?"' ~Z T lm a faClhl> ; W a bC .n opucal storage device connected to an opticai scanner. 

unable to gam access to the necessary documents. Also, 40 JT^ , _ _ . . *, , 

valuable time can be wasted in the instance of organ ^ documents are scanned by the optical scanner and 
donations in trying to gain authorization from relatives. slored J n an °Pj IcaI stora * e ° ther information is 

These documents may also need to be periodically entered ,nt0 data stora 8 e fcohliei connected to the 
reviewed and revised as the laws change or situations computer. Requests for information can be received by 
are altered. The documents may be legally sufficient at 45 t | ie depository from remote locations by data transmis- 
the time of execution, but as legislation changes, the sion devices, such as telephone, facsimile or electronic 
documents may be no longer valid. Also, a document ma "* • The depository will process these requests, to 
executed in one jurisdiction may not be valid in another verify that the request applies to a customer of the de- 
jurisdiction where the individual later resides. pository, and that the person making the request is au- 

In the situation of accidents or death, it may be diffi- 50 thorized to receive the information. The authorized 
cult to verify insurance coverage, including health in- request for information and documents can then be 
surance and life insurance. Life insurance policies are processed and the appropriate information and docu- 
often stored in inaccessible locations, thus slowing the men ts retrieved and transmitted to the person making 
benefit payments. Also, it may be awkward to verify lne request. 

health insurance coverage for treatment in remote loca- 55 ^ system ^ provides a procedure for updating 

U ° 1 } s ' .u a , . . _ , the information and documents as legislation regarding 

Another related problem ,s m f.ndmg compatible the s , ored MoraMkm and docume ^ s changes 8 A)so 8 

donors for bone marrow transplants. Typically, in the # . r . . 

instances where a bone marrow transplant is necessary. S >£ em m0m i 0rs for cha °«f m residence which 

the donee must ask for volunteers. There is no centrai 60 may affecl the informat,on and documents. 

index for potential donors to be cross-typed according s y stem of lhe P resent mv ention provides a secure 

to compatibility. depository for important information and documents 

Therefore a need exists for a central depository which may be rapidly retrieved from almost any geo- 

which can solve these and other problems. graphical location. 

65 These and other features of the claimed invention will 

SOLUTION TO THE PROBLEM become evident from the ensuing detailed description of 

The present invention provides a national depository a preferred embodiment taken in conjunction with the 

for filing of such documents as living wills, durable drawings. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows an overview of a preferred embodi- 
ment of the present invention. 

FIG. 2 is a flow chart of the application process of the 5 
present invention 

FIG. 3 is a flow chart of the periodic updating of the 
system. 

FIG. 4 is a flow chart of the updating of documents 
after a change of address. m 10 

FIG. 5 is a flow chart of the tracing procedure of the 
system. 

FIG. 6 is a flow chart of the request processing pro- 
cedure of the system. 

DETAILED DESCRIPTION OF A PREFERRED 15 
EMBODIMENT 

1. Overview of a Preferred Embodiment 

The present invention provides a central depository 
for important documents, such as living wills (express- 20 
ing and authorizing the "right to die"), durable powers 
of attorney and other collateral documents including 
testamentary wills, authorizations for organ and bone 
marrow donations, and insurance information. The gen- 
eral public has increasingly become aware of the need 25 
to express, in advance, the preference and right to re- 
fuse medical treatment in the event of imminent death 
or permanent unconsciousness. The present invention 
provides a safe central repository for such "right to die" 
documents, including living wills and durable powers of 30 
attorney and a system for management and retrieval of 
these documents and associated information. This sys- 
tem is also suited as a repository for related documents 
such as testamentary wills and authorizations for organ 
and bone marrow donations as well as information such 35 
as health and life insurance. 

A general overview of a preferred embodiment of the 
present invention is illustrated in FIG. 1. It is to be 
expressly understood that this descriptive embodiment 
is for explanatory purposes only and is not meant to 40 
limit the scope of the claimed inventive concept. Other 
variations and embodiments are considered to be within 
the scope of the inventive concept. 

2. System Configuration of a Preferred Embodiment 45 

The central depository 10, shown in FIG. 1, can be 
physically located at almost any location. The deposi- 
tory includes computer 12 having data input 20 Input 20 
includes data input device 22, such as a keyboard or 
mouse, and optical scanner 24, for processing applica- 50 
tions. The application information 14 can be manually 
entered through the data input device 22 while any 
documents 16 can be scanned in by optical scanner 24. 
Communications device 30. which includes modem 3 
inputs information into computer 12; in addition, it re- 55 
ceives requests for information and documents and 
transmits information from the system. 

The information from the application is verified by 
computer 12 and stored in data storage 40. Separate files 
are set up for each customer according to the desired 60 
service. Customer document file 42 is set up to store 
information on each particular customer, such as back- 
ground information, billing information and identifying 
information as discussed in greater detail below. Insur- 
ance file 44 is set up to store information relating to life 65 
insurance and health insurance if the customer desires. 
Information regarding potential organ donation is 
stored in donor information file 46. Bone marrow infor- 
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mation file 48 is set up for information on potential bone 
marrow transplant donors. Living will information is 
stored in living will file 50 and durable power of attor- 
ney information is stored in durable power of attorney 
file 52. Testamentary will file 54 is set up to store infor- 
mation regarding the testamentary will and codicils of 
the customer. Legislative review file 56 is set up to 
periodically review and update any necessary informa- 
tion and documents as legislation is updated. 

Documents scanned by optical scanner device 24 are 
stored in optical storage 60. Many jurisdictions are 
recognizing, for legal purposes, documents stored on a 
Write-Once, Read-Many Times (WORM) drive CD- 
player, without requiring production of the original 
documents. Document stored on WORM-drives are 
unalterable; therefore, they should be sufficient for legal 
purposes. Documents relating to authorization for 
organ donation are stored in donor authorization form 
file 62. Living will documents are stored in living will 
document file 64. Durable power of attorney file 66 is 
set up to store durable power of attorney documents. 
Testamentary wills are stored in testamentary will file 
68. 

Archive 70 is available for physically storing the 
original documents. Archive 70 will typically be a fire- 
proof vault or underground cavern or the like to se- 
curely store the original documents. 

Depository 10 further includes computer output 80. 
Output 80 includes printer 82 to print out the stored 
information, documents 86, and reports 88 and screen 
device 84. Communications device 30 also can serve as 
an output device for computer 12 to directly transmit 
data to remote locations. 

Computer 12 includes operating systems, discussed in 
greater detail below, to verify the applications for accu- 
racy and completeness, for entering information and 
documents to the appropriate files, and for processing 
requests for information and documents. Computer 12 
also periodically reviews the files and documents for 
legislative updates and for jurisdictional requirements in 
regard to customer changes of residences. Billing sys- 
tems are also in place to alert customers to upcoming 
fees and to bill the customers for such fees. The system 
is also capable of updating customer information as 
necessary and purging the depository of any informa- 
tion and documents regarding inactive customers. 

Processing the application: 

Depository 10 typically operates as illustrated in 
FIGS. 2-5. As indicated in the chart illustrated in FIG. 
2, the customer sends to depository 10, as indicated in 
block 200, a completed application form including in- 
formation, such as the customer's name, date of birth, 
social security number, current address, mother's 
maiden name, next of kin, and insurance information, as 
well as the necessary documents, such as a living will, 
durable power of attorney, testamentary will and autho- 
rization for donation of organs and bone marrow. This 
application is received at the receiving office of deposi- 
tory 10 where it is processed, at decision block 202. 
either manually or by a computerized system. The in- 
formation is checked for completeness as well as obvi- 
ous errors. If the information is incomplete or in error, 
the application, at block 204. is returned to the customer 
with a request for additional information. Once the 
application is complete, the information and documents 
are entered, at block 206. into the depository. 
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A customer information file 42 is created for each the system is able to verify, as discussed in greater detail 

customer and a unique file number is assigned with a below, the customer's documents for validity as legisla- 

code identifying the state of residence of the customer. tion is updated. This information is stored, at block 234, 

This could be the customer's social security number or in legislative review file 56. 

a number generated by the depository. Initially, the 5 The system, at decision block 236, determines if the 

customer's reference information is entered into the customer wishes information and documents relating to 

system. This reference information includes such infor- their testamentary will and codicils stored. The system 

mation as the customer's name, date of birth, social moves to decision block 246 if the customer this service, 

security number, current address and mother's maiden then information regarding the testamentary will and 
name or other significant identifying information. This 10 codicils is entered, and then stored at block 240 into 

information, at block 208, is stored in customer informa- testamentary will file 54. At decision block 242 the 

tion file 42. system determines whether there are documents to be 

The system then moves to decision block 210 for scanned. If not, then the system moves on to decision 

insurance information. If the customer does not desire block 246 for durable power of attorney. If there are 

insurance information to be stored, then the system will 15 documents to be scanned, then these documents are 

move on to decision block 216 for organ donor authori- stored, at block 244, into optica] storage 60 in testamen- 

zation. However, if requested by the customer, insur- tary will file 68. 

ance information is entered, at block 212, into the sys- The system at block 246 determines whether to input 
tern. The insurance information will be stored, at block information and documents relating to the durable 
214, in insurance file 44. This will allow for the retrieval 20 power of attorney. This typically is a companion docu- 
of critical information for prompt notification of the ment to the living will and testamentary will A durable 
insurance company at the time of need or death and to power of attorney creates a power of attorney which 
insure that all benefits or proceeds are made immedi- will survive incapacitation of the customer. This is nec- 
ately available to the appropriate parties. essary in order for the appointee to be able to execute 
The next step, at decision block 216, is to determine 25 the wishes of the living will. If storage of a durable 
Whether organ and bone marrow donation is to be power of attorney is not desired, then the system moves 
authorized. If the customer does not wish to authorize on to decision block 260. If a durable power of attorney 
organ donation, then the system moves to decision is to be stored, then information and documents regard- 
block 224 for living wills. However, if the customer ing the durable power of attorney is entered, at block 
wishes to authorize organ donation, then the system, at 30 250. The information is stored, at block 252, into dura- 
block 216, will identify which vital organs are desired to ble power of attorney file 52. The documents are 
be donated as well as the possible use of the customer's scanned, at block 254, into optical storage 60, in durable 
body for potential scientific study. This information is power of attorney file 66. 

stored, at block 220, into donor information file 46. The system inputs, at block 256, legislative review 

Donor authorization forms, if necessary, are scanned at 35 information regarding the durable power of attorney, 

block 222 and stored in optical storage 60 in donor Legal requirements differ from jurisdiction to jurisdic- 

authorization form file 62. tion and may periodically be revised. The system veri- 

Also, at block 218, if the customer wishes to be in- fies the accuracy of the customer's durable power of 

dexed for potential bone marrow transplants, then this attorney according to their residential jurisdiction and 

information will be stored, again at block 220, in bone 40 periodically verifies these documents as legislation is 

marrow information file 48. This information will be revised. This information is stored, at block 258, into 

available to authorized individuals who are on a list of legislative review file 56. 

those individuals who have been typed for bone mar- The original documents are either sent back to the 

row transplants and are willing to be available for such customer (not shown), or if the customer requests, 

transplants This information would be available imme- 45 stored in an safe and secure archive 70 operated by the 

diately to streamline the matching of potential donors depositary. 

and recipients. The system, at decision block 260, determines if there 

The system, at decision block 224, determines if liv- are any more applications to be processed. If there are 

ing will information and documents are to be entered more applications to be processed, then the system 

into the system. If the customer does not desire this 50 moves back to block 200 and repeats the process as 

service, then the system moyes to decision block 236 for necessary. If there are no more applications waiting to 

testamentary wills If the customer wishes to store living be processed, then the system prepares a status report, 

will documents, then the system inputs living will infor- at block 262. The system verifies that this report is 

mation at block 226 into the system. The living will correct and moves to block 266. If necessary, the report 

expresses the customer's right and preference to have 55 is edited, at block 264, then the system moves to block 

medical support terminated under certain detailed con- . 266. 

ditions, involving imminent death or permanent uncon- The system at block 266 reviews the financial status 
sciousness. Information regarding the customer's living of the processed applications. The funds that were gen- 
will is stored at block 228 into living will file 50. The erated by the processing of the applications are then 
living will documents are stored, at block 230, into 60 deposited, at block 268, in an appropriate location, 
optical storage 60, in living will document file 64. It is to be expressly understood that the embodiment 
The system next inputs, at block 232, legislative re- described above is for explanatory purposes and is not 
view information into the system. The legal require- meant to limit the scope of the inventive concept. For 
ments for living wills may differ from state to state. instance, the system of the present invention can pro- 
Therefore the living will information is checked rela- 65 cess the information in'any number of sequential steps 
tive to the requirements of the state in which the cus- and in any order of processing the information and 
tomer resides This information is readily flagged by the documents, 
unique identification code on the customer's file. Also. Updating the system: 
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The system of the present invention provides the tomer. Typically this will be a close relative, or some- 
capability to periodically and automatically update the one to be notified in the event of an emergency. The 
stat us of the files stored therein. The system does this by system produces a notice, in block 506, to the desig- 
three procedures. nated person or entity requesting a new address for the 

The first procedure, shown in FIG. 3, updates the 5 customer. After a predetermined passage of time, the 
legislative review data periodically. As the statutory system moves to decision block 508 to determine 
requirements evolve in each jurisdiction, the system whether a new address for the customer has been re- 
will note these changes. Periodically, or as legislation ceived. If a new address has not been received, then the 
affecting the validity of stored documents is revised, the system moves to block 510 to purge the system of the 
system will enter the customer files, as shown in block 10 customer data and documents. Normally the system 
300, in FIG. 3. The system, in block 302, will enter each will move the information flies and document files to an 
customer's files, and, at blocks 304, 306, and 308, the inactive status for a designated period of time after 
system will extract billing data and legislative review which the system will purge all information and docu- 
data therefrom. ments from the system. 

The system then enters decision block 310 to deter- 15 If a new address for the customer is received, then the 
mine if billing is due to the customer. If not, then the system, in block 512, will enter the change of address 
system proceeds to decision block 314. If the customer into the system. The customer information file 42, in 
is due to be billed, then a billing notice is produced at block 516, will be retrieved and updated, in block 514, 
block 312. The system then moves on to decision block with the new address. In block 514, the system will also 
314. 20 retrieve legislative review file 56 to review the jurisdic- 

The system at decision block 314 determines if the tional requirements for the stored documents. In deci- 
living will is still valid after the legislative revisions. If sion block 520, the system will determine whether the 
the living will is still valid, then the system moves onto documents are still valid in the new residential jurisdic- 
decision block 318. If the living will is no longer valid, tion. If the documents are still valid, then in block 522 
then the system at block 316 produces an expiration 25 the system will produce a report to that effect, 
notice for the customer. The system then moves onto If the documents are no longer valid, then, in block 
decision block 318. 524, the system will identify which documents are no 

The system at decision block 318 determines if the longer valid. The system will then, in block 526, pro- 
durable power of attorney is still valid after the legisla- duce a report to the customer identifying the invalid 
tion revisions. If the durable power of attorney is still 30 documents and requesting new executed documents to 
valid, then the system moves onto block 322 to produce be sent to the depository. ■ 

a monthly report. If the durable power of attorney is no Utilization of these procedures provides the customer 
longer valid, then the system at block 320 produces an with automatic and periodic verification and update on 
expiration notice. The system then moves onto block the status of the information and documents stored in 
322. 35 the depository. 

At block 322. the system produces a monthly report Processing requests for information: 
of all activities generated by the system and the status of The depository system provides rapid processing of 
the files and documents. requests for the information and documents stored 

The second updating procedure also occurs, shown there. The processing operation is shown in FIG. 6. A 
in FIG. 4. automatically. Once a customer changes 40 telephone request, in block 600, facsimile request, in 
address and sends in a change of address to the system, block 602, mail request 604, or other data transmission 
this change of address is entered into the system, as request 606, for information or documents regarding a 
indicted in block 400. Customer information file 42, in particular customer is received and entered into the 
block 404, is retrieved, and the new change of address, system. 

in block 402. is updated. Also in block 402, information 45 The system, in decision block 608, first verifies that 
from legislative review file 56. retrieved in block 406, is the person on which the information or documents is 
reviewed. The system, in block 408, reviews the docu- requested is a customer of the depository. If the person 
ments which have been previously stored to determine is not a customer, then, in block 610, the request is 
whether they are still valid in the new residential juris- denied. If the person is a customer, then, in block 614, 
diction. If the documents are still valid, then the system, 50 the system verifies that the person or entity making the 
in block 410, produces a report to this effect. If the request is authorized to receive the information and 
documents are no longer valid, then the system in block documents. This is done by retrieving customer infor- 
412 identifies the documents which are no longer valid. mation file 42 and checking for prior authorization or 
A report, in block 414, is produced and sent to the for prior authorized procedures. If the person or entity 
customer identifying the invalid documents and re- 55 making the request is not authorized to receive the 
questing new documents to be executed. information or documents, the request, in block 618, is 

The third procedure, illustrated in FIG. 5, involves a denied, 
tracing procedure for customers who have moved with- Once a request has been authorized, then the system 
out notifying the depository of their change in address. moves to block 620 to retrieve the requested informa- 
Each customer is periodically billed for the costs of the 60 tion from insurance file 44, organ donation file 46 bone 
depositary service A returned mail notice is entered into marrow transplant file 48, living will file 50, durable 
the system, at block 500, if the bill is returned because power of attorney file 52 or testamentary will file 54. 
the customer is no longer at that address. The system The system then in block 622 retrieves requested docu- 
then. at block 502. retrieves customer information file ments from authorization form file 62, living will docu- 
42. in block 504. and requests the new address option. 65 ment file 65 durable power of attorney file 66 or testa- 
The new address option includes the name and address mentary will file 68. 

of a person or entity that the customer designated who The retrieved information or documents are then, in 
will provide notification of the whereabouts of the cus- block 624, transmitted via the appropriate transmitting 
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device to the person or entity making the request. Doc- 
uments and reports can be transmitted in block 626 via 
mail or facsimile transmission. Information can also be 
transmitted via screen display, in block 628, directly 
over telephone requests. Also the information data can 
be directly transmitted over the communications device 
30, in block 630, to a receiving terminal. 

Billing systems are utilized (not shown) to charge the 
appropriate fees for the services. 

Examples of the processing of requests for various 
information and documents are described below. It is to 
be expressly understood that these examples are for 
descriptive purposes only and are not meant to limit the 
scope of the claimed inventive concept. The system of 
the present invention is capable of various embodiments 
and modifications and the below described examples are 
for explanatory purposes only. 

Example of request for living will: 

A request for the living will documents is received by 
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device whether a particular person is a client of the 
center, or if there is a particular HLA type noted for 
potential bone marrow donation. 

In the event that there is an affirmative answer to the 
caller's inquiry, the caller will be instructed to call a 
"900" number to make the desired request for informa- 
tion or documents. The caller will provide information, 
including the identity of the caller and reason for re- 
questing the information. The system will verify to 
ascertain whether the caller is authorized to receive the 
requested information or documents, either by prior 
authorization from the customer's files or by operation 
of law. 

If the caller is authorized to receive the information, 
then the system will verify that the customer has re- 
quested that information regarding their Human Leuko- 
cyte Antigens (HLA) typing be provided to appropriate 
medical facilities or doctors. The HLA typing provides 
an indication of the compatibility between potential 



the processing system by a toll-free 800 number, facsim- 20 organ donors and recipients and potential bone marrow 

donors and recipients. 

The customer can also indicate that they be notified 
for permission prior to such information being pro- 
vided. If the request is authorized, then upon payment, 
via "900" telephone charge or other payment system, 
the information is transmitted to the caller. 
Example of request for testamentary will: 
The caller calls the "800" number to ascertain 
whether a person is a customer of the center. The indi- 
30 vidual can ascertain from the answering device whether 
a particular person is a customer of the center. 

In the event that there is an affirmative answer to the 
individual's inquiry, the individual will be instructed to 
call a "900" number to make the desired request for 
information or documents. The caller will provide in- 
formation, including the identity of the caller and rea- 
son for requesting the information. The system will 
verify to ascertain whether the caller is authorized to 
receive the requested information or documents, either 



ile, mail, electronic mail or other data transmission de 
vices. The request is checked against the customer file. 
If the information is on file, then the requesting entity 
can be notified, if a toll-free 800 number was used, to 
call a "900" telephone number, for billing purposes, or 25 
other payment/billing device to receive the informa- 
tion. 

After the requesting entity has done so, then the pro- 
cessing system verifies that the requesting entity is au- 
thorized to receive the information and documents. 
This may be by prior authorization contained in the 
customer's files, or by operation of law; 

If the requesting entity is authorized to receive the 
information and documents, then the information is 
retrieved and transmitted to the requesting entity. This 35 
can be by electronic transmission, by telephone, by 
facsimile or other data transmission devices. The docu- 
ments can be retrieved from the optical storage device 
and mailed to the requesting entity. 



The center will purge the information and documents 40 by prior authorization from the customer's files or by 



from the system, once it has been notified that the cus- 
tomer is deceased. 

Example of inquiry for organ donation: customer's 
desire to donate organs or body portions should the 
customer be declared dead. At the appropriate time, a 45 
medical facility may call an "800" number to verify if a 
patient is a customer of the center. This can be done by 
an automatic answering device. If the center verifies 
that the patient is a customer, then the medical facility 
is given further instructions to call a "900" 
another data transmission device. 

The medical facility will provide pertinent informa- 
tion as to the customer, such as name, social security 
number, date of birth and the like. If that customer has 
indicated their desire to be a donor, then the center will 
provide to the requesting facility, if authorized, a copy 
of the donor card and information by electronic trans- 
mission or other data transmission devices. If necessary* 
a certified copy of the original document will be pro- 
vided from the archives or from the optical data stor- 60 
age. 

Example of request of compatibility typing: 
The appropriate entity, normally a medical facility or 
medical doctor, calls the "800" number for inquiries as 
to whether a person is a customer of the center, in the 65 
case of organ donation, or if a specific Human Leuko- 
cyte Antigen (HLA) type is available, for bone marrow 
donation. The caller can ascertain from the answering 



operation of law. 

If the caller is authorized to receive the information, 
then a copy of the information, such as the testamentary 
will, is transmitted to the caller after a charge has been 
made via the "900" telephone service. 

The original of the testamentary device, or a certified 
copy, can be provided upon receipt of a certified copy 
of the death certificate of the customer. The death cer- 
tificate information will be entered into the system and 
number or 50 the customer will be removed from the active files to 
the inactive files, and eventually purged from the sys- 
tem. 

If the caller is not authorized to receive the informa- 
tion, then they can send a written request stating rea- 
sons for needing the information, a certified copy of the 
death certificate, and the appropriate fee. A copy of the 
testamentary device may then be transmitted to the 
requestor. 

Example of request for insurance information: 
The caller calls the "800" number to ascertain 
whether a person is a customer of the center. The indi- 
vidual can ascertain from the answering device whether 
a particular person has information, such as a Living 
Will, Durable Power of Attorney, insurance informa- 
tion, organ donation information or testamentary will, 
stored at the center. 

In the event that there is an affirmative answer to the 
individual's inquiry, the individual will be instructed to 
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call a "900" number to make the desired request for means for indexing said information regarding organ 
information or documents. The caller will provide in- and bone marrow donors of said customers accord- 
formation, including the identity of the caller and rea- ing to specific types. 

son for requesting the information. The system will 5. The system of claim 1 wherein said means for en- 
verify to ascertain whether the caller is authorized to 5 tering said documents include an optical scanning de- 
receive the requested information or documents, either vice. 

by prior authorization from the customer's files or by 6. The system of claim 5 wherein said data storage 

operation of law. means include a CD-ROM player device for storing 

If the caller is authorized to receive the information, said documents scanned by said optical scanning device, 
then a copy of the information, such as health insurance 10 7. The system of claim 1 wherein said system further 

if the customer has been in an accident or sudden illness, includes means for verifying said documents and said 

is transmitted to the caller after a charge has been made customer information for completeness, for errors, and 

via the "9(XT telephone service. for legislative changes. 

Likewise, life insurance policy coverage can be ascer- 8. The system of claim 1 wherein said system further 

tained via the same procedure. Also, once a certified 15 includes means for updating changes of said residential 

copy of the death certificate is provided to the center, a addresses of said customers. 

copy of the life insurance policy, or the original if neces- 9. The system of claim 1 wherein said system further 

sary, can be transmitted to the beneficiaries. includes 

The present invention provides a central depository 2Q means for preparing billing information in regard to 

for providing secure storage and rapid access to impor- customers information as well as the current 

tant documents and information, and a system for ad- status of said stored documents and customer infor- 

ministering this depository. The system as claimed is not mation; and 

meant to be limited to the above description of a pre- means f ° r providing said billing information and sta- 

ferred explanatory embodiment, but encompasses other 2 5 tus t0 Mid customer. 

embodiments and modifications. The claimed invention 10 - The system of claim 1 wherein said system further 

is not meant to be limited for use with only the above includes means for updating any new customer informa- 

described documents and information but further en- tion and means for Paging information relating to inac- 

compasses other documents and information as the need tlve customers from said system. 

ar j ses 30 11. The system of claim 1 wherein said means for 

We claim: processing requests includes: 

1. A svstem for administering a central depository for means for reiving said request for information and 
living wills and other associated documents and cus- documents pertaining to a particular customer; 
tomer information for health care purposes, said system means for v enfymg that information is present in said 
comprising- 35 dala stora g e means for said particular customer; 

data storage means for storing documents and cus- " means for retrieving said requested information and 

tomer information, said documents including said documents from said data storage means; and 

living wills and other associated documents; said transmitting means delivering said requested 

means for entering said documents into said data information and documents to the entity making 

storage means; 40 ™<* request. 

means for entering said customer information into 12 The system of , C \T 11 ™* eTCm said means for 

said data storage means; processing requests further includes: 

™ ,.^f.,: ~ .u . j u r a means for verifying that said entity making said re- 

means for verifying that said documents fulfill the . w receive f ed mfor _ 

legal requirements of said customers residential ^ rior to transmitti said re J, e$ted mfor _ 

jurisdiction; ™ mation and documents. 

means for periodically updating said legal require- J3 The of cWm , whercin said mean$ for 

men s and verifying that said documents still fulfill transmitting M m f orm ation includes: 

the legal requirements of sa.d customer s restden- means for transmitting data to a remote data receiv . 

tial jurisdiction; ing terminal. 

means for processing requests for said documents and u A $ystem for administering a centra , depository 

said customer information from said data storage for , jving wiHs> durab , e powm of atton)ey for heallh 

mean * ; . . care purposes, and other associated documents and 

means for retrieving said documents and customer custoraer information; said system comprising: 

information in response to said requests; and 55 data storage means for storing documen ts and cus- 

means for transmitting said requested documents and tomer information, said documents including said 

customer information. l ivmg durable powers of attorney, and other 

2. The system of claim 1 wherein said documents associated documents: 

include durable powers of attorney for health care pur- optical scanning means Vor entering said documents 

P oses - 60 into said data storage means for storage; 

3. The system of claim 1 wherein said other associ- means for entering said customer information into 
ated documents further include testamentary wills, in- said data storage means for storage: 

surance policies and authorization forms for organ and means for receiving requests for information and 

bone marrow donation. documents pertaining to a particular customer; 

4. The system of claim 3 wherein said system further 65 means for verifying that information is present in said 
comprises means for entering information regarding data storage means for said particular customer; 
poiential organ and bone marrow donors of said cus- means for verifying that the requestor is authorized to 
tomers; and receive the requested information and documents; 
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means for verifying said information and documents 
for completeness, errors, and that said documents 
fulfill any jurisdictional legal requirements; 

means for periodically updating said verification for 
legal requirements; 

means for retrieving the requested information and 
documents; and 

means for transmitting the requested information and 
documents to said requestor. 

15. The system of claim 14 wherein said system fur- 
ther comprises: 

means for updating information relating to customers 
having documents and information stored in said 
system; and 

means for updating legal requirements for each cus- 
tomer. 

16. The system of claim 14 wherein said system in- 
cludes: 

means for preparing billing information for said cus- 
tomers; 

means for preparing status reports for said customers; 
means for updating information relating to said cus- 
tomers; and 

means for purging the system of documents and infor- 
mation of inactive customers. 

17. A method of administering a central depository 
for living wills, durable powers of attorneys, and other 
associated information, said method comprises the steps 
of: 

processing an application from a customer; 
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entering documents pertaining to said customer into 30 



verifying that documents and information regarding 
that particular customer exists in the archival sys- 
tem or the data storage means; and 

verifying that the request is authorized. 

21. The method of claim 17 wherein said step of pro- 
cessing requests for documents and information in- 
cludes the steps of: 

receiving said request for documents and informa- 
tion; 

verifying that documents and information for a par- 
ticular customer is stored in said archival system or 
said data storage means; 

confirming to the entity requesting the documents 
and information that such documents and informa- 
tion exist; and 

notifying said entity of the procedure and charge to 
receive said documents and said information. 

22. The method of claim 21 wherein said step of pro- 
cessing requests for documents and information in- 
cludes the step of: 

verifying that the entity making the request is autho- 
rized to receive said requested information and 
documents. 

23. The method of claim 17 wherein said step of trans- 
mitting said information and documents includes: 

transmitting said information and documents directly 
to a remote location. 

24. A method of administering a central depository 
for living wills, durable powers of attorney, and other 
associated information, said method comprises the steps 
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an archival system, said documents including said 
living wills and said durable powers of attorney, 
wherein said step of entering documents into an 
archival system including the steps of: 

(a) scanning said documents by an optical scanning 
device; and 

(b) storing said scanned documents in a data stor- 
age means; 

entering information regarding said customer into 
said data storage means: wherein said step of enter- 40 
ing information regarding said customer into said 
data storage means further includes the steps of: 

(a) periodically entering information regarding 
legislative review pertaining to said documents 
into said system; and 

(b) periodically verifying the legal sufficiency of 
said documents in response to said legislative 
review information; 

processing requests for documents and information 

regarding said customer; 
retrieving documents and information in response to 

said requests; 

transmitting said requested documents and informa- 
tion to the entity making said requests. 

18. The method of claim 17 wherein said step of pro- 
cessing an application from a customer includes the 
steps of: 

verifying that said application is complete; 
verifying that said application is error-free; and 
verifying that any documents to be stored are legally 60 
sufficient. 

19. The method of claim 17 wherein said step of stor- 
ing said scanned documents in said data storage means 
includes storing said scanned documents in a CD-ROM 
player. 

20. The method of claim 17 wherein said step of pro- 
cessing requests for information and documents of a 
particular customer includes the steps of: 
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processing an application from a customer; 
entering documents pertaining to said customer into 
an archival system, said documents including said 
living wills and said durable powers of attorney; 
entering information regarding said customer into a 

data storage system; 
processing requests for documents and information 

regarding said customer; 
retrieving documents and information in response to 

said requests; 
transmitting said requested documents and informa- 
tion to the entity making said requests; 
periodically verifying the place of residence of said 
customers; 

updating any changes of address of said customers; 
and 

reviewing said documents and information for legal 
sufficiency in the new residential jurisdiction. 

25. The method of claim 24 wherein said step of peri- 
odically verifying the place of residence of said custom- 
ers further includes: 

tracing any change of address by contacting an au- 
thorized person in said customer's information for a 
new change of address. 

26. The method of claim 25 wherein said method 
further comprises: 

placing any customer's information and documents in 

an inactive file should the customer's location be 

unable to be verified; and 
after a predetermined amount of time, purge said 

customer's information and documents from said 

inactive files. 

27. The method of claim 24 wherein said method 
further comprises: 

indexing bone marrow type and organ types of any 
customer who desires to be a potential donor; and 

providing the indexed information to appropriate 
entities for possible cross-matching. 
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ABSTRACT 



A medical records system that creates and maintains all 
patient data electronically. The system captures patient data, 
such as patient complaints, lab orders, medications, 
diagnoses, and procedures, at its source at the time of entry 
using a graphical user interface having touch screens. Using 
pen-based portable computers with wireless connections to 
a computer network, authorized healthcare providers can 
access, analyze, update and electronically annotate patient 
data even while other providers are using the same patient 
record. The system likewise permits instant, sophisticated 
analysis of patient data to identify relationships among the 
data considered. Moreover, the system includes the capabil- 
ity to access reference databases for consultation regarding 
allergies, medication interactions and practice guidelines. 
The system also includes the capability to incorporate legacy 
data, such as paper files and mainframe data, for a patient. 

46 Claims, 26 Drawing Sheets 
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ELECTRONIC MEDICAL RECORDS abnormal laboratory test results, prescribed medications to 

SYSTEM address the abnormality, and specific treatments adminis- 
tered by the physician, may not be apparent within a patient 

FIELD OF THE INVENTION file. 

The present invention relates to electronic healthcare 5 In the current environment, specific patient data is difBcult 

systems, and more particularly, to a system for storage and 10 access wnen needed for analysis. The creation of patient 
retrieval of electronic medical records in a computer data in remote locations exacerbates this problem. In 

environment, such as a local or wide area network including addition, the wide variety of data formats for patient data 

portable computers. hinders electronic processing and maintenance of patient 

l° files. Moreover, the use of a patient's file by one healthcare 

DESCRIPTION OF RELATED TECHNOLOGY provider can preclude its simultaneous use by another 

lT ... . . . . , healthcare provider. Ongoing consolidation of healthcare 

Healthcare providers, such as physicians, create large .. : t . i_ i.iT-. • _• 

. c \ * c .- < . . r .u ■ providers into large health maintenance organizations 

volumes of patient information during the course of their >ti*_^ \ i r _ i • \ 

business at healthcare facilities, such as hospitals, clinics, 1S (HMOs) and preferred provider organizations (PPOs) create 

... , !• i «_ t- i i_ issues in the transfer and maintenance of patient data in large 

labora tones and medical offices. For example, when a . . . i _» j 

...... . . . - - „ . _. T . . . enterprises having numerous remote locations. Under these 

patient visits a physician for the first time, the physician r . , & ... . , , .. 

r _ i __• ___ .••» j- circumstances, healthcare providers have difficulty provid- 

generally creates a patient file including the patient s medi- . __?_-._ __•._.• _• . 

, . J . 4 . . * • , ■ - , mg effective treatment for their patients, 

cal history, current treatments, medications, insurance and ° r 

other pertinent information. This file generally includes the 2Q SUMMARY OF TOE INVENTION 
results of patient visits, including laboratory test results, the 

physician's diagnosis, medications prescribed and treat- The electronic medical record (EMR) system of the 

ments administered. During the course of the patient present invention automates and simplifies existing methods 

relationship, the physician supplements the file to update the of patient chart creation, maintenance and retrieval. In 

patient's medical history. When the physician refers a 25 contrast to other systems, the present invention creates and 

patient for treatment, tests or consultation, the referred maintains all patient data electronically and thus can elimi- 

physician, hospital, clinic or laboratory typically creates and nate or supplement creating and maintaining of physical data 

updates similar files for the patient. These files may also records. The EMR system finishes healthcare providers with 

include the patient's billing, payment and scheduling an intuitive, easy-to-use, icon-based interface that enables 

records. 30 them to capture and analyze patient data quickly and effi- 

Healthcare providers can use electronic data processing to ciently. Using the present invention, healthcare providers 

automate the creation, use and maintenance of their patient enter patient data immediately at the point of care. Thus, the 

records. For example, in U.S. Pat. No. 5,277,188, assigned EMR system captures each piece of data at its source at the 

to New England Medical Center Hospitals, Inc., Selker timc of entr Y to provide a complete audit trail for all patient 

discloses a clinical information reporting system having an 35 data. In this manner, the EMR system transforms a patient 

electronic database including electrocardiograph related chart fr o m a static record of a few clinical interactions into 

patient data. Similarly, Schneiderman discloses a computer a dynamic, real-time comprehensive record linked to an 

system for recording electrocardiograph and/or chest x-ray enterprise-wide clinical database. In addition, the EMR 

test results for a database of patients in U.S. Pat. No. system of the present invention includes the capability to 

5,099,424. In U.S. Pat. No. 4,315,309, Coli discloses a 40 manage a wide variety of patient data formats, including 

patient report generating system for receiving, storing and patient data from external sources, such as laboratories and 

reporting medical test data for a patient population. Mitchell, pharmacies. The EMR system can also incorporate a 

in U.S. Pat. No. 3,872,448, likewise discloses a system for patient's legacy data, such as a paper chart, into the patient 

automatically handling and processing hospital data, such as record as well as legacy data from mainframe computers, 

patient information and pathological test information using 45 The present invention likewise provides instant access to 

a central processing apparatus. In U.S. Pat. No. 5,065,315, a patient's electronic medical record by authorized health- 

Garcia discloses a computerized scheduling and reporting care providers from any geographical location. Thus, the 

system for managing information pertinent to a patient's EMR system enables authorized healthcare providers to 

stay in the hospital. However, these electronic data process- access and update patient files using wireless pen-based 

ing systems can not handle patient data in the wide variety 50 personal computers. To enable complete replacement of 

of data formats typically produced by healthcare providers, physical records, the present invention permits healthcare 

such as physicians, laboratories, clinics and hospitals. providers, such as physicians or nurse practitioners, to 

Physicians often use paper based forms and charts to electronically annotate patient data. Thus, a healthcare pro- 
document their observations and diagnosis. Laboratories vider can acknowledge reviewing patient data, provide 
also produce patient data in numerous forms, from x-ray and 55 instructions, such as prescriptions for medication to admin- 
magnetic resonance images to blood test concentrations and ister to a patient, and approve recommendations for treat- 
electrocardiograph data. Clinics and hospitals may use a rnent by other providers, all by electronically annotating a 
combination of paper based charts and electronic data for patient's record. In addition, authorized healthcare providers 
patient records. The same patient data may exist in remote can access a record while other providers use the same 
patient files located at clinics, hospitals, laboratories and 60 record allowing for real-time collaboration. The availability 
physicians'offices. Similarly, patient files at one healthcare of electronic data permits instant, sophisticated analysis of 
provider typically have different information than patient patient data. Moreover, the EMR system enables enhanced 
files at another healthcare provider. When in use, patient files analysis of patient data by providing access to reference 
are generally not available to other healthcare providers. In databases for diagnosis, procedures and medication, 
addition, at the time of creation, patient data is generally not 65 One aspect of the present invention includes a medical 
available for use by remotely located healthcare providers. records system, comprising a point of care system to capture 
Moreover, relationships among specific patient data, such as patient data at a point of care and a patient data repository, 
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in communication with the point of care system and with FIG. 10 is a block diagram illustrating the structure of a 

external systems, to store and organize the patient data for practice guideline in the point of care system of FIG. 4. 

access by the point of care system. p IG u ^ a block diagram illustrating the structure of the 

Another aspect of the present invention includes a medi- medication data capture and the practice guideline in the 

cal records system comprising a point of care system to 5 p 0 f nt 0 f care system of FIG. 4. 

capture data in a patient record at a point of care, wherein the i^- 4 ,.u M i. < i'.- . n ♦ #• .u . r*u 

\. . j- t j • «j t't* , FIG. 12 is a block diagram illustrating the structure of the 

patient record includes a patient identifier and at least one t . . , , ° f CI/ , ~ & 

j , i . . t c ** . • j . « « patient data repository of FIG. 1. 
data structure including the patient identifier and the data. 

Yet another aspect of the present invention includes a } 13 is a bl ° ck ***** grating the structure of a 

medical records system comprising a point of care system to 10 P alient record Wllhin lhe P atient data repository of FIG. 12. 

capture data at a point of care and a patient data repository, FIG - 14 15 an example of the patient record of FIG. 13. 

in communication with the point of care system and with FIG. 15a is a flowchart illustrating the process flow of the 

external systems to store and organize the data in a patient patient data repository of FIG. 12. 

record for access by the point of care system, wherein the FIG. 156 is a flowchart illustrating the process for a 
patient record includes a patient identifier and at least one 15 transfer of data from a cache to a data archive in the patient 

data structure including the patient identifier and the data. data repository of FIG. 12. 

In addition, another aspect of the present invention FIG. 16 is a block diagram iUustrating the structure of the 

includes a method of using an electronic medical records d ata interface of FIG 12 

system comprising the steps of capturing patient data dec- FIG. 17a is a flowchart'illustrating the process flow of the 

ironically at the point of care , « the pat.ent data so 20 ^ rf ^ ^ ^ ^ F da(a 

as to form a patient record, filing the patient record, and aQ external 
retrieving the patient record to access the patient data for use 

in the care of a patient FIG. \7b is a flowchart illustrating the process flow of the 

Yet another aspect of the present invention includes a data interface of nG 16 wheD '"nsmitting patient data to 

method of retrieving patient data in an electronic medical 25 an ex erna source * 

records system having a patient data repository, comprising FIG - 18 * a block diagram illustrating the structure of the 

the steps of obtaining a patient identifier, locating a patient reference database of FIG. 1. 

record corresponding to the patient identifier in the patient FIG. 19 shows an example of a graphical user interface of 

data repository, and determining the location of the patient the point of care system of FIG. 4 having a reference access 

data within the patient record. 30 button and a medication manager button. 

Another aspect of the present invention includes a method FIG. 20 shows an example of a graphical user interface 

of managing a patient data repository having a cache and a for the diagnosis module and the procedure module of the 

data archive, comprising the steps of monitoring a status of reference database of FIG. 18. 

data within the cache, and moving the data to the data FIG 2 \ shows an example of a graphical user interface 

archive when the status exceeds a threshold. for the medication manager of the reference database of FIG. 

Still another aspect of the present invention includes a 18. 

methodofcommunicatingwithancxternalsourcehavingan FIG. 22 shows an example of a medication interaction 

interface to an electronic medical records system, compris- of tne medication manager of FIG . 2 1. 

ing the steps of finding an interface for the external source, .„ . 

connecting to the external source using the interface, and 40 , 23 is a block diagram illustrating the structure of the 

converting patient data for transfer between the external legacy data system ot HO 1 

source and the electronic medical records system. FIG - 24 k an example of a typical configuration for the 

electronic medical records system of the present invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 3 F 

FIG. 1 is a block diagram illustrating the electronic 45 DETAILED DESCRIPTION OF THE 

medical record (EMR) system architecture of the present PREFERRED EMBODIMENTS 

invention. f 0 ii owing detailed description of the preferred 

FIG. 2 is a flowchart illustrating the process flow of the embodiments presents a description of certain specific 

EMR system of the present invention. embodiments to assist in understanding the claims. 

FIG. 3 shows an example of a graphical user interface of However, one may practice the present invention in a 

the EMR system useful for the scheduling of a patient multitude of different embodiments as defined and covered 

appointment as shown in FIG. 2. by the claims. 

FIG. 4 is a block diagram illustrating the structure of the For convenience, the description comprises three sec- 
point of care system of FIG. 1. 55 ti ons: E MR System Architecture and Overview, EMR Sys- 

FIG. 5 shows an example of a graphical user interface of tern Configurations and Summary. The first section provides 

the point of care system of FIG. 4. an overview of the EMR system architecture, the following 

FIG. 6 shows an example of a new form window of the section describes EMR system applications and preferred 

point of care system of FIG. 4. embodiments for practicing the EMR system of the present 

FIG. 7 shows an example of an annotate window of the 60 invention, and the remaining section summarizes advanta- 

point of care system of FIG. 4. geous features of the present invention. 

FIG. 8 shows an example of a viewer window displaying w M- , . , _ 

an image of patient data of the point of care system of FIG. S y slem Architecture and Overview 

4 FIG. 1 illustrates the architecture of the EMR syslem. 

FIG. 9 is a block diagram illustrating the structure of a 65 Healthcare providers, such as physicians, at hospitals, labo- 

medication data capture in the point of care system of FIG. ratories and clinics, generally capture and access patient data 

4. using a point of care system 100 that communicates with a 
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patient data repository 102. Patient data, such as vital signs, an appointment date and an appointment time. An adjacent 

x-ray images and laboratory results, resides in the patient box, such as the date box 126, displays the selected date and 

data repository 102. The patient data repository 102 also time. Lastly, the healthcare provider enters a textual descrip- 

communicates with external sources to obtain patient data, tion of the patient's complaint in a reason box 127. Note that 

such as laboratory test results and x-ray images, and to 5 the healthcare provider can review prior or future scheduled 

transfer patient information, such as prescriptions for appointments by clicking on the appointments button 128. 

medication, from the EMR system to other healthcare pro- Similarly, the healthcare provider can track referrals by 

viders. The point of care system 100 captures patient data in entering the identity of persons who referred this patient to 

real-time at the point of care, that is, where healthcare their care in the referral box 129. 

providers interact with their patients. For example, physi- J0 Referring now to FIG. 4, a block diagram illustrates the 
dans can use a point of care system 100 to enter, access, structure of the point of care system 100. The point of care 
process, analyze and annotate data from patient records in system 100 includes the following modules: a patient data 
real-time at the point of care. Thus, using the point of care capture 140, a clinical data capture 142, progress notes 144 
system 100, a physician, who has many patients in a and an encounter data capture 146. During a patient visit, the 
hospital, can visit each patient in their room, access their 15 healthcare provider (not shown) can enter, review and anno- 
electronic patient record there, enter results of the current tate patient information, such as family history, 
examination, evaluate their medical history, electronically appointments, current medications and complaints, using the 
annotate their x-rays images and prescribe medications and patient data capture 140. The healthcare provider can like- 
treatments instantaneously as the point of care system 100 wise enter, review and annotate clinical data obtained during 
captures and organizes patient data into the patient record 2 o the visit, such as body temperature and blood pressure, using 
stored in the patient data repository 102. The point of care the clinical data capture 142. Similarly, the healthcare pro- 
system 100 may likewise communicate with a reference vider can enter laboratory data for patients with the clinical 
database 104 to assist a healthcare provider in making data capture 142. The clinical data capture 142 communi- 
diagnoses, prescribing medications and administering treat- cates with the patient data capture 140 to assist in identifying 
ments. Moreover, the patient data repository 102 may also 2 s needs for further clinical data. For example, a family history 
communicate with a legacy data system 106 to access of high blood pressure may indicate a need to obtain the 
pertinent patient data in paper files and mainframe electronic patient's blood pressure during the visit. The patient data 
databases. capture 140 also communicates with the encounter data 
Referring now to FIG. 2, a flowchart illustrates the capture 146, where a healthcare provider can enter, review 
operation of the EMR system. For example, a patient having 30 and annotate data regarding diagnoses and procedures 
a complaint contacts a healthcare provider 110, such as a administered to the patient. Moreover, the healthcare pro- 
physician, to schedule an appointment. The EMR system vider can use the progress notes 144 to summarize details of 
obtains the patient record 111 from the patient data reposi- the patient's condition and to review the patient's progress 
tory 102 (FIG. 1) prior to the scheduled appointment. The over time. Thus, the progress notes 144 communicates with 
EMR system is also capable of handling patients on a 35 the patient data capture 140, the clinical data capture 142 
walk-in basis by scheduling an appointment and requesting and the encounter data capture 146. 
the patient's record immediately thereafter. The EMR sys- Referring now to FIG. 5, in a preferred embodiment, the 
tern updates the patient record 112 to include the complaint point of care system 100 (FIG. 1) includes a graphical user 
and other information pertinent to the appointment, such as interface having a patient chart window 150 to capture 
insurance information. A healthcare provider, such as a 40 patient information. The point of care system 100 presents a 
physician, examines the patient 113 using the point of care patient record graphically using a tabbed layout to organize 
system 100 (FIG. 1) to make a diagnosis and to treat the patient data. The patient chart window 150 includes tabs for 
patient's condition. As determined at 114, if a diagnosis is patient data 151, clinical data 152, encounter data 153 and 
not possible on the basis of this examination, the physician progress notes 154. Pointing and clicking on a tab on the 
may need to obtain additional clinical data 115, such as 45 patient chart window 150 opens a folder window 155 where 
laboratory tests and x-rays. When available, the physician a healthcare provider can enter and review patient data 
uses the point of care system 100 (FIG. 1) to evaluate the within the folder. For example, to activate progress notes 
results 116 and to examine the patient 113 again in light of 144 (FIG. 4), the healthcare provider selects the progress 
the results. Upon making a diagnosis, the physician may notes tab 154 to display a list of progress note data in the 
need to prescribe medications 117 for the patient's condi- 50 folder window 155. In a similar manner, to activate the 
tion. Similarly, the physician may need to administer a patient data capture 140, the clinical data capture 142 or the 
treatment 118 to address the patient's condition. At the encounter data capture 146, one selects the patient data tab 
conclusion of the patient's visit, the EMR system files the 151, the clinical data tab 142, or the encounter data tab 153, 
patient's record 119 in the patient data repository 102 (FIG. respectively. 

1) for future reference. 55 To enter patient data, the healthcare provider clicks on the 

In a preferred embodiment, the EMR system includes scroll down button 156 to select a form from a list of 

graphical user interfaces to access system functions. For available forms to enter patient data. This activates the new 

example, as shown in FIG. 3, a chart puller window 120 forms box 157. The provider then points and clicks on the 

enables a healthcare provider to schedule a patient appoint- new form button 158. For example, FIG. 6 shows a new 

ment using its point and click interface. To schedule an 60 form window 161 displaying the pediatric problem form 162 

appointment, a healthcare provider activates the select but- selected by the healthcare provider using the scroll down 

ton 121 with a pointing device, such as a mouse or electronic button 156 (FIG. 5). The healthcare provider fills out the 

pen, to obtain a list of patients. The healthcare provider then pediatric problem form 162 using an input device, such as a 

scans the list to select the name of the appropriate patient keyboard, a mouse or an electronic pen. For example, the 

using a pointing device. The EMR system places the name 65 provider uses a keyboard to enter text "6/7/96 Stomach 

of the selected patient in the patient box 123. Similarly, the Ache" 164 and an electronic pen to enter initials 166 for 

healthcare provider uses the up/down buttons 125 to select identification. When done with patient data entry, the pro- 
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vider exits the form using the File Menu 168 and the point the patient data capture 140 and with the progress note 144. 

of care system 100 returns the provider to the patient chart Similarly, the practice guideline 149 communicates with 

window 150 (FIG. 5). Referring back to FIG. 5, the new patient data capture 140, the clinical data capture 142, the 

form appears as the top entry of the list in the folder window encounter data capture 146 and the progress note 144. 

155. 5 However, the practice guideline 149 may now communicate 

Similarly, to annotate patient data, the healthcare provider with the medication data capture 148 to address situations 

first selects an item to annotate by pointing and clicking on where accepted practice guidelines require a healthcare 

the item in a list displayed in the folder window 155. The provider to prescribe and administer medications. In a 

provider then clicks on the annotate button 159 to open the preferred embodiment, the point of care system 100 includes 

item in an annotate window 170, as shown in FIG. 7. For 10 tne graphical user interface illustrated in FIG. 5. Referring 

example, the annotate window 170 of FIG. 7 displays a back to FIG. 5, the patient chart window 150 includes tabs 

blood test result 172. As before, the healthcare provider for medication data 191 and practice guidelines 193 that 

annotates the blood test result document 172 using an input activate the medication data capture 148 and the practice 

device, such as a keyboard, a mouse or an electronic pen. For guideline 149, respectively. Similarly, pressing the medica- 

example, the provider uses a keyboard to enter text "Out of 15 tion manager button 192 activates the medication data 

Range" 174 and an electronic pen to circle 176 the out of capture 148 and the practice guideline 149. A healthcare 

range result. When done with annotations, the provider exits provider can enter, review and annotate patient medication 

the form using the File Menu 178 and the point of care data and practice guideline data as described previously, 
system 100 returns the provider to the patient chart window Referring now to FIG. 12, a block diagram illustrates the 

150 (FIG. 5). Note that the point of care system 100 tracks 2 o structure of the patient data repository 102. The patient data 

the review of patient data and identifies reviewed files with repository 102 includes a patient locator 200, a data manager 

a mark 160 in the folder window 155. By annotating patient 202 and a data interface 204. The patient locator 200 

data, a healthcare provider, such as a physician, can generates a unique patient identifier (PID) 221 (FIG. 14) for 

acknowledge reviewing patient data, provide instructions, each patient and creates and maintains a table having PIDs 

such as directions for additional tests and procedures or 25 f° r all patients who have data in the patient data repository 

prescriptions for medication to administer to the patient, and 102. All data records related to a patient 211, 212, 213, 214, 

approve recommendations for treatment by other healthcare 215, 216, 219 include and reference the patient's unique PID 

providers. Lastly, as shown in FIG. 8, a healthcare provider as shown in FIG. 13. 

uses the patient chart window 180 to view patient data. First, With reference to FIG. 13, upon creation of a patient 
the healthcare provider selects a view item 182 by either 30 record, the patient locator 200 creates a patient data structure 
pointing and clicking twice on the item in a list displayed in 210 having the PID and the patient's name. In a preferred 
the folder window 184 or by pointing at the item in the list embodiment, the patient data structure 210 includes pointers 
and pressing the view button 183. The double click opens a to data structures having data within a patient record cap- 
viewer window 185 to display the view item 182. For tu red by the point of care system 100 and incorporated from 
example, the viewer window 185 of FIG. 8 displays an x-ray 35 external sources (e.g., a digital x-ray image file stored in a 
186. As before, the healthcare provider may annotate the raster pixel format). Thus, the patient data structure 210 
x-ray 186 with comments and observations by clicking on maintains a pointer to an interface files structure 211 having 
the annotate button 187. The healthcare provider may like- patient data transmitted from external sources. The patient 
wise close the viewer window 185 by. clicking on the close data structure 210 likewise maintains pointers to a clinical 
button 189. 40 data structure 212, a progress note structure 213 and an 
Certain additional structures in the point of care system encounter data structure 214. These data structures include 
100 (FIG. 1) will now be discussed with reference to FIGS. patient data captured by the clinical data capture 142, 
9, 10 and 11. Referring now to FIG. 9, an optional medica- progress notes 144 and encounter data capture 146, respec- 
tion data capture 148 supplements the structure of the point tively (FIG. 4). In another preferred embodiment, the patient 
of care system 100 of FIG. 4. A medication data capture 148 45 data structure 210 may include pointers to data structures 
allows a healthcare provider to monitor a patient's medica- having data generated by the reference database 104 and 
tions. The medication data capture 148 communicates with transferred by the legacy data system 106. Thus, the patient 
the patient data capture 140 to account for medications the data structure 210 may maintain pointers to a medication 
patient is currently taking. The medication data capture 148 data structure 215 and a guideline data structure 216. As 
similarly communicates with the progress notes 144, where 50 described above, the medication 215 and guideline 216 data 
a practitioner can monitor changes in a patient's condition structures include patient data captured by the medication 
resulting from medication therapies. Referring now to FIG. data capture 148 and the practice guideline 149, respec- 
10, an optional practice guideline 149 supplements the tively. In this embodiment, a reference data structure 217 
structure of the point of care system of FIG. 4. The practice may maintain pointers to the encounter data structure 214 
guideline 149 provides references for practitioners to consult 55 and to the medication data structure 215 for access to 
regarding courses of action to obtain a diagnosis and alter- reference information contained in a reference database 104. 
native treatments for various conditions. The practice guide- Lastly, the patient data structure 210 may maintain a pointer 
line 149 communicates with the patient data capture 140, the to a legacy files structure 219 having patient data transmitted 
clinical data capture 142 and the encounter data capture 146 from the legacy data system 106, such as an image of a 
to assist the practitioner in selecting the appropriate course 60 patient chart. 

of action. The practice guideline 149 likewise communicates FIG. 14 shows a logical view of a patient record 220 

with the progress notes 144 to provide a healthcare provider corresponding to the structure illustrated in FIG. 13. The 

with a historical context of the patient's condition and patient record 220 includes the PID generated by the patient 

alternative treatments already attempted. locator 200 (FIG. 12) in the patient data repository 102 (FIG. 

FIG. 11 shows a point of care system 100 having a 65 1). In addition, the patient record 220 includes patient data 

medication data capture 148 and a practice guideline 149. As in a variety of data types generated by healthcare providers, 

before, the medication data capture 148 communicates with Thus, the patient record includes text data 223, such as 
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electronic mail and word processing documents from other when data requested for storage in the cache would exceed 
healthcare providers, image data 225, such as scanned its memory capacity. In this circumstance, the data manager 
physical documents, x-rays and CATSCANs, and audio data 202 first transfers to the data archive 208 signed files and 
227, such as a physician's dictation and voice mail. Lastly, then data files in chronological order, i.e., oldest files first, 
the patient record 220 has data tables 229, such as a 5 Similarly, a healthcare provider can specify a predetermined 
physician's ICD9 diagnosis codes and CPT procedure time, such as 3 calendar days, or other selected conditions 
codes. In view of the structure of a patient record 220, for transfer to the data archive 208. As determined at 262, if 
referring back to FIG. 12, the data manager 202 uses the PID the cache 206 does not have the data to transfer, the process 
to store and retrieve patient records. Moreover, the data ends as the data manager 202 ignores the request. As 
interface 204 permits communication with external sources 10 determined at 264, if the data in the cache 206 is not ready 
to obtain patient data, such as demographic data, laboratory for transfer, the process ends and the data manager 202 
test results and x-ray images, and to transfer patient queues the request for the next transfer of data to the data 
information, such as prescriptions for medication, from the archive 208. Data in the cache 206 is ready for transfer when 
patient data repository 102 to external healthcare providers. a physician has reviewed and accepted it and when it has not 
With reference to FIG. 12, the patient data repository 102 15 been previously committed to the data archive 208. 
may optionally include a cache 206 for temporary storage of Otherwise, the data manager 202 transfers data from the 
patient data and a data archive 208 for long term storage of cache 206 to the data archive 208 at 266. 
patient data. In this embodiment, the data manager 202 Referring now to FIG. 16, the data interface 204 of the 
coordinates the transfer of patient data to and from a data patient data repository 102 includes an interface manager 
archive 208 into a cache 206. For example, the data manager 2 o 270, a data handler 272 and a communication interface 274. 
202 may identify patient records that a healthcare provider To transfer and receive patient data from external sources 
needs for appointments scheduled at a future time and then (not shown), the interface manager 270 communicates with 
transfer these patient records from the data archive 208 into a data handler 272 and a communication interface 274. In 
the cache 206 for quick access prior to the scheduled addition, the communication interface 274 communicates 
appointment. Similarly, the data manager 202 may purge 25 with the data handler 272 for conversion of received external 
from the cache 206 records of patients who have not had patient data into formats recognized by the EMR system, 
recent appointments and whose records are already The interface manager 270 creates and maintains an inter- 
archived. The data manager 202 likewise tracks the location face registry of data formats for external sources. Prior to 
and description of patient data within the data archive 208 by data transfer or receipt by the EMR system, the interface 
associating the file name of the patient data within a patient 30 manager 270 registers an interface for an external source, 
record 220 with the patient identifier 221. When possible, Upon registration of an interface, the interface manager 270 
the data manager 202 will group data associated with a can provide the appropriate conversion routines for the data 
patient within the data archive 208 for rapid retrieval in a handler 272 to use for transfer of data to and receipt of data 
manner similar to files within a directory in an operating from an external source. These conversions are well under- 
system. Thus, the data manager 202 assigns a directory to 35 stood by the relevant technologist. 

each patient identifier and then stores patient data within this FIGS. 17a and 17b illustrate the operation of the data 

directory. interface 204 of the patient data repository 102 (FIG. 12). 

FIG. 15a illustrates the process flow for the patient data Referring now to FIG. 17a, the data manager 202 issues a 
repository 102 (FIG. 1). For example, the point of care request 280 for patient data from an external source. At 282, 
system 100 (FIG. 1) issues a request for patient data 250. 40 the interface manager 270 determines if the registry includes 
With reference to FIGS. 15a and 12, the patient locator 200 an interface for the external source, such as a laboratory or 
receives the request from the point of care system 100 and, pharmacy. As determined at 282, if the registry includes an 
at 251 attempts to find the PID for the record having the interface for the external source, the communication inter- 
requested patient data. As determined at 252, if no PID is face 274 connects to the external source 284 to receive 
found, the patient locator 200 reports an error 253. At this 45 patient data. The data handler 272 retrieves the appropriate 
point, the patient data repository 102 (FIG. 1) may recover conversion routine for the external source to convert data 
from the error 253 by either restarting the process or by 286. In a preferred embodiment, the data handler 272 
ending the process. Otherwise, the patient locator 200 com- converts data from an external source into a database table 
municates the PID to the data manager 202. The data for the appropriate PID. Lastly, the data manager 202 
manager 202 locates the patient record using the PID at 254. 50 incorporates converted data 288 into the patient record. 
As determined at 255, in a system without cache 206 and Otherwise, the interface manager 270 reports an error 289. 
without a data archive 208, the data manager 202 delivers The data manager 202 may recover from the error 289 in 
the requested data 256 to the point of care system 100. In a several ways. First, the data manager 202 may invoke a 
system having a cache 206 and a data archive 208, the data module to register an interface for the external source so as 
manager 202 determines at 257 if the requested data exists 55 to allow the process to continue. Second, the data manager 
in the cache 206. If so, the data manager 202 delivers the 202 may end the process at this point. Lastly, the data 
requested data 256 to the requester from the cache 206. manager 202 may restart the process in the event the external 
Otherwise, the data manager 202 first moves the data 258 source was specified incorrectly. 

from the data archive 208 to the cache 206 and then delivers Referring now to FIG. 176, an external source requests 

the requested data 254 to the requester from the cache 206. 60 data 290 from a patient record. As described above, the 

In addition, FIG. 156, in conjunction with FIG. 12, interface manager 270 determines at 292 if the registry 

illustrates the process for transferring data from a cache 206 includes an interface for the external source. As determined 

to a data archive 208. The data manager 202 monitors the at 292, if the registry includes an interface for the external 

contents of the cache 206. To improve the performance of source, the data manager 202 locates the requested data at 

the cache 206, the data manager 202 requests transfer 260 of 65 294 and the data handler 272 converts requested data at 296 

data to the data archive 208 under certain conditions. For to the format required by the external source. The commu- 

examplc, the data manager 202 may purge the cache 206 nication interface 274 then sends the converted data to the 
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externa] source at 298. For example, the patient data reposi- button 314 activates a medication manager window 350. The 

tory 102 may transmit a physician's prescription for medi- physician can review the patient's history by viewing the 

cation to a hospital or pharmacy. If the registry includes no medication history box 351 and the diagnosis history box 

interface for the external source, the interface manager 270 352 before prescribing any new medications. The physician 

reports an error 299. Similarly, as discussed above for the 5 can rcv i e w any patient allergies in the allergy box 353. 

process flow of FIG. 17a, the interface manager 270 may ^ physician can select a medication by entering the name 

recover from the error 299 by restarting the process, ending of the medication in lhe name box 354. Note that as the 

the process or invoking a module to register the external physician cnters thc root letters of a rae dication name, a list 

source to allow the process to continue. of medicalions ^ ^ root letters appears in the medica . 

Referring now to FIG. 18 a block diagram illustrates the J0 ^ ust 5ox 355 M ^fac, the physician selects a medi- 

structure of the optional reference database 104 (FIG. 1). cation from tbe Hsl by cIicking on it and the medication 

The reference database 104 includes a diagnosis module manager 30 2 places the selected medication in a selection 

300, a medication manager 302 and a procedure module box 356 If there are nQ contraindications or ^ lcT ^ QS for lhc 

304. A healthcare provider can use the reference database patienty the physician prescribes the medications listed in the 

104 for assistance in diagnosing a patient's disease, pre- J5 selection box 356 by clickiog on the p resc ribe button 357. 

scribing medications and ordering supplemental procedures * ■ j- *• 

. . j. ^ j . . ^ . ~* Otherwise, if a contraindication exists, a warning appears 

to treat the disease. The diagnosis module 300 commum- . . # , ^ 4 . . ■ ■ , ■ * *u 

. , . & ™« . , . - - c ma warning bar 358 to alert the physician. In view of the 

cates with a medication manager 302 to obtain information # . 0 , «■ . r , L 

*• . • t-u i- warnmg, the physician can investigate the effects of the 

on medications indicated by a diagnosis. The medication 7. , , . . 0 . „ -- n „ r 

•a* j • r j . . medication by chckmg on the results button 359. Referring 

manager 302 provides information on medications, such as ~ n , \~ 0 K , „ , . & 

& , ,, • . « . . • « 20 now to FIG. 22, the results button produces a medication 

proper dosages, allergies, contra indications, adverse inter- . 4 . , n-* A j- 1 *■ i. 

-.u *u i- 4- , . . ff , t. interaction window 361. A medication selection box 362 

actions with other medications, and side effects. The diag- t . . . . . , 

a 1 iftnn j displays the medications selected and under consideration 

nosis module 300 likewise communicates with a procedure . r .. J . . . A „ . . - ~ ,. , . 

1 1 <*i\a Li • • r i_ « . . by the physician. An allergy list box 363 displays the 

module 304 to obtain information on the proper admin*- atient ./ a ,| . Fo | dcr ta £ 364 include |abels £ J ribi 

tration of procedures indicated by a diagnosis. The proce- ~ c , . 4 . , . . 4 . ™ , . . 

« , , .j • r - j 25 the medication combinations and mteractions. The physiaan 

dure module 304 provides information on procedures for , Ct , c . . t , .. .. 

w clicks on one of these folder tabs 364 to display the contents 
treatment as indicated by the diagnosis. In many instances, r ., ^ , , ... . , rp. s : . . 
t . ,. * M & . . * . of the folder m the viewing box 365. The physiaan can then 
the medication manager 302 communicates with the proce- , . . . c . - • , 
j * , & .. 1 ... . • r - evaluate the mformation on the interaction including poten- 
dure module 304 regarding the administration of various , , .•«■•• u • • r 1 *u 
medications adverse patient reactions. The physician clicks on the 
, " , . , . 30 d o ne button 366 to return to the medication manager win- 
In a preferred embodiment, the point of care system 100 dow 350 of nG 21 ^ physician can make needed 
provides access to the reference database 104 through a reyisions {Q the medicalions selected in lhe manner 
graphical user interface having a patient chart window 310 described above . Afterwards, the physician exits the medi- 
shown in FIG. 19. A healthcare provider accesses the calioQ man ef 3Q2 b dicki QQ ^ ^ buUon 36Q 

diagnosis module 300 and the procedure module 304 by n r t ^ 7, , .„ . 

... • t*i* c u . <»*<i Referring now to FIG. 23, a block diagram illustrates the 

pointing and cl.ck.ng on a reference access button 312. strucmre <jf b lhe a , da(a ^ 1M as shown fa 

As shown in FIG. 20, the reference access button 312 p, G j ^ , data 106 indudes a data SQUrce 

produces a reference window 330 including the graphical 370 ^ a ajnverter 3?2 ^ da(a 37() com rises 

mterfaces for the diagnosis module 300 and the procedure h ka , da|a 374> such as based recor(Js and 

module 304. For example to enter a diagnose a physician 40 p hotographS( and electronic mainframe data 376. The con- 

dicks on the scroll down button 331 adjacent to the system verter 372 receives informalion from the data 370 

box 332 to produce a Ust of body systems. Tbe physician and transforms ^ information into an electronic format 

selects the appropriate system and the diagnosis module 300 compalible wilh tbe EMR syslem . For example> to iDpul 

enters the selected system in the system box 332 and h ical data 3?4> such ^ ef Qr ^ ^ 6 ^ [q{0 a 

provides a list having specific diagnosis codes for the 45 patient record , the converter 372 comprises a scanner to 

selected body system in the diagnosis box 334. The physi- di itize thc h ical data into a w fi|c format for 

cian 1 then 1 selects the appropriate diagnosis code and clicks mcorporation int0 the patient>s record . To ^ elec tronic 

on theadd button 336 adjacent to the diagnosis selection box mainframe data 376> the converter 372 employs the same 

337. The diagnosis module 300 enters the selected diagnosis mechanism used for tnMfcr or recei , of tient data from 

code to the diagnosis selection box 337. Thc physician may 50 external sources . M described before, the converter 372 

repeat the above steps to add multiple diagnosis codes to the delermines if an ^tfox exists for the mainframe data, 

diagnosis select sdects tfae a riale data handler and lhe data 

uses the scroll down button 331 adjacent to the topic box 333 ^ the format for int0 a patient record> 
to select the appropriate procedure topic. Hie procedure 

module 304 enters the selected procedure topic in the topic 55 u - EMR Svstem Configurations 

box 333 and provides a list of procedure codes in the FIG. 24 illustrates one possible configuration for the EMR 

procedure box 335. The physician now selects the appro- system of the present invention. The system comprises a 

priate procedure code and adds it to the procedure selection wide area network (WAN) 402, the World Wide Web (Web) 

box 338 by clicking on the add button 336 adjacent to the 404 portion of the Internet, and remote web servers 406, 

procedure selection box 338. The physician may likewise 60 408, 410 communicating with web browsers 412. The WAN 

repeat the above steps to add multiple procedure codes to the 402 comprises a plurality of local area network (LAN) 

procedure selection box 338. The physician completes entry servers supporting local and remotely located healthcare 

of diagnoses and procedures by clicking on the done button providers. For example, the WAN 402 includes LANs sup- 

339 to return to the patient chart window 310 of FIG. 19. porting Scripps Health 414 and Sharp Memorial 430 in San 

The healthcare provider similarly accesses the medication 65 Diego and Cedars Sinai 432 and Loma Linda 434 in Los 

manager 302 (FIG. 18) by clicking on a medication button Angeles, Calif. In one presently preferred embodiment, the 

192 (FIG. 19). Referring now to FIG. 21, the medication server comprises a multi-processor personal computer hav- 
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ing Intel Pentium processors, such as a Compaq Proliant definition, data access, security, programming language 

4500R 5/100 Model 2, communicating with a fault tolerant, interface and data administration. The SQL-92 standard 

error correcting storage device, such as a Hewlett Packard specifies data definition, data manipulation, and other asso- 

20XT Optical Jukebox having 20 gigabytes of storage ciated facilities of a DBMS that supports the relational data 

capacity. The LAN 400 includes a backup server 426 and 5 mo del. SQL is old in the art and additional information on 

several peripherals, such as a scanner 424 to input docu- SQL-92 is available in ANSI specification X3.135-1992, 

ments and a laser printer 422 to print out documents. In a hereby incorporated by reference. 

preferred embodiment, the LAN backbone comprises an Similarly, in another preferred embodiment, relational 

Ethernet twisted pair cable configured in a general star databases in the EMR system support the 0pe n Database 

^ZBJ™^' thC S £T ef *™f mpr !? S 3 , FUJlt f 10 Connectivity (ODBC) model. ODBC is an application pro- 

M3093EX scanner using Kofax KIPP ImageControls soft- mterfacc (Ap]) that allows diem applicalions mnning 

ware and the laser printer 422 comprises a Hewlett Packard undef Microsoft windows to access data from a varietv of 

LaserJet 4Plus. Healthcare providers may access the LAN data sourccs> including re htional and non-relational DBMS. 

400 using a desktop computer 416, a laptop computer 418 or ncsc data sources may feside on a clieQt machine Qf lh 

wireless pen computer 420. In a preferred embodiment the J5 may 5e located on a remQte xtvei communicating lhrough 

desktop computer 416 comprises a Compaq Deskpro 5/75 a netWQrk common tQ the c[ient machine Under QDBC, 

Model 630, the laptop computer 418 comprises a IBM data SQ}aces {n ^^Hy from shrink-wrap 

ThinkPad 760CD and the pen computer 420 comprises a dalabases> such ^ Microsoft Access, running under Win- 

Fujitsu Stylist 1000 configured with a Solectek AirLAN dows on a cUent machine tQ more sophisticated) propr ietary 

PCMCIA network adapter for wireless LAN access. The 20 relational DBMS mnning on a Unix server or main f rame 

EMR system also provides for communication through the computen For a client app i ication to access data from a data 

World Wide Web. For example, remote healthcare providers a d fc link Hb (DLL) driver must exist fof 

may access the WAN 402 on the Web using the domain eacfa dala SQUrce {Q be accessed Fof addilional informalioQ 

name www.westcst.com 436. Thus, a healthcare provider on 0DBC is available from Inside QDBC by Karl Geiger> 

located in Boston, Mass. may access a patient record resi- 25 hefeby incorporated by reference. 

dent on the Scripps Health server 414, located in San Diego, 

Calif., using a web browser 412, such as Microsoft Explorer N- SUMMARY 

or Netscape Navigator, communicating with a Web server in The electronic medical record system of the present 

Boston, Mass. having the domain name "www.boston.com" invention advantageously overcomes several limitations of 

406. 30 existing technologies and alternatives. Because it is more 

In a preferred embodiment, servers 414, 426, desktop 416, efficient and cost effective to move data, instead of physical 

or laptop 418 computers and peripherals, such as printers records and healthcare providers, the present invention 

422 or scanners 424, communicate with each other and with eliminates the need to create and maintain any physical data 

the Web using a network operating system, such as records. In contrast to other systems, the present invention 

Microsoft Windows NT, Windows 95 or Windows for Work- 35 creates and maintains all patient data electronically. Thus, 

groups. Similarly, pen computers 420 use the Microsoft there is no need to find, pull, move, update, file and replace 

Windows for Pen Computing operating system. In another physical charts. As a result, healthcare providers no longer 

preferred embodiment, the servers, computers and periph- require substantial shelving and storage space for physical 

erals communicate using an operating system supporting files. The present invention likewise eliminates the 

Web browsers on computer networks, such as Unix, Novell 40 mishandling, loss and destruction of patient data typically 

Netware or Apple System 7.0. In yet another preferred associated with maintenance of physical data records, 

embodiment, the EMR system includes servers, computers Using the present invention, healthcare providers enter 

and peripherals networked using mixed network operating patient data immediately at the point of care. Thus, the EMR 

systems, such as Unix, Netware and Windows. For example, system captures each piece of data at its source at the time 

the LAN 400 may operate on a Windows NT network 45 of entry, including time and healthcare provider identifica- 

operating system, whereas the LAN 430 may operate on an tion. The EMR system thus provides a complete audit trail 

Apple System 7.0 network, and the Web server "www.bos- for all patient data. The audit trail, in turn, permits inexpen- 

ton.com" 406 may operate on a Unix operating system. sive analysis of outcomes, utilization and compliance. For 

Thus, the EMR system supports communication among a example, outcomes typically refer to the effectiveness of a 

variety of hardware components, such as printers 422, 50 treatment plan. Thus, the EMR system enables a healthcare 

scanners 424 and pen computers 420, using a variety of provider to analyze patient recovery times and incurred costs 

network operating systems, such as Windows, Netware or to measure the efficacy of the treatment plan. Similarly, 

Unix. In a preferred embodiment, healthcare providers, such utilization typically refers to how well available resources 

as clinics and laboratories, may also communicate with the are utilizing time. Thus, the EMR system provides the 

EMR system using modem links and standard v.34 modem 55 capability to analyze utilization of physicians, nurses, staff 

devices, such as a US Robotics Sportster 28,800 modem. and equipment as well as time utilization for patients, such. 

The EMR system includes several databases of electronic as wait times for referrals, lab results and physician exami- 
information, such as the medication manager 302 and the nations. Lastly, compliance typically refers to conformance 
data manager 202. In a preferred embodiment, the EMR with government and accreditation standards and regula- 
system implements a relational database language that con- 60 tions. The EMR system provides tools to enable healthcare 
forms to American National Standards Institute (ANSI) providers to measure conformance to standards and regula- 
standard SQL-92, a 580 page specification for the SQL tions. To facilitate entry of patient data at the point of care, 
relational database language. A database language standard the invention provides touch screens for entry of lab orders, 
specifies the semantics of various components of database medications, diagnoses and procedures. The invention like- 
management systems (DBMS). In particular, it defines the 65 wise provides instant access to a patient's electronic medical 
structures and operations of a data model implemented by record by authorized healthcare providers from any geo- 
the DBMS, as well as other components that support data graphical location. Thus, the EMR system enables autho- 
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rized healthcare providers to access and update patient files 
using wireless pen-based personal computers. In addition, 
authorized healthcare providers can access a record while 
other healthcare providers use the same record- By provid- 
ing simultaneous access to patient data, the present inven- 5 
lion enables real-time collaboration among multiple health- 
care providers. 

The availability of electronic data permits instant, sophis- 
ticated analysis of a patient's clinical data. Thus, the EMR io 
system can create graphs of a patient's vital signs and lab 
results or the system can provide an analyze patient infor- 
mation to identify medication interactions and allergies. 
Using the present invention, a healthcare provider can 
likewise select, sort, and analyze patient data to identify 15 
relationships among the data considered. In addition, the 
EMR system provides flexibility in the creation and main- 
tenance of patient data repositories. Thus, the present inven- 
tion can support a large healthcare enterprise distributed 
across a large geography as well as a single physician ofiBce. 20 
Moreover, the present invention ensures patient confidenti- 
ality through the use of a tiered password system. The EMR 
system provides several levels of security for access to 
patient data. For example, a system administrator may have 
global password access to any patient data for system 25 
maintenance and debug purposes, whereas physicians may 
have access only to patient records within their specialty and 
nurses and staff may have access to only those patient 
records within their immediate care. In addition, a patient 
may request restricted access to their data by only certain 30 
personnel. Thus, in contrast to physical records, the EMR 
system provides superior protection of patient data. 

In addition, the present invention is useful in legal, 
manufacturing and general administration environments. 
For example, the present invention is capable of organizing, 
maintaining and protecting legal files in an attorney's office. 
Thus, the EMR system can store and retrieve scanned 
images of paper documents, such as deeds and assignments, 
as well as other native file formats, such as word processing 
files. The EMR system organizes and retrieves this data in a 
manner akin to that of a patient's medical record. Upon entry 
of a client data into the EMR system, attorneys can annotate 
documents, transfer information to and from other systems, 
or create new data for automatic filing in the client or case 
file. Similarly, the EMR system is useful for management of 
procurement or regulatory data in a manufacturing context. 
Thus, the EMR system can organize and maintain material 
safety data sheets (MSDS) as well as other data pertinent to 
materials procurement, such as conformance to specification 
measurements and inspection data for received lots, in a 
manufacturing environment. Lastly, the EMR system is 
useful for general administrative files in any organization. 
For example, the present invention is applicable to employee 
files in human resources, customer files in sales and 
approved suppliers in procurement. The EMR system can 
organize and retrieve data within these files in the manner as 
patient data in a patient data record. As discussed above, 
upon entry of a data into the EMR system, users can annotate 
documents, transfer information to and from other systems, 
or create new data for automatic filing in the respective file. 

Those skilled in the art may practice the principles of the 
present invention in other specific forms without departing 
from its spirit or essential characteristics. Accordingly, the 
disclosed embodiments of the invention are merely illustra- 
tive and do not serve to limit the scope of the invention set 
forth in the following claims. 
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What is claimed is: 

1. A medical records system, comprising: 

a point of care system to capture patient data at a point of 
care wherein the point of care system comprises: 

patient data capture to enter information provided by a 
patient, 

a clinical data capture, in data communication with the 
patient data capture to enter clinical data for the patient, 

an encounter data capture, in data communication with 
the patient data capture, to enter diagnoses and proce- 
dures administered to the patient, and 

progress notes, in data communication with the patient 
data capture, the clinical data capture and the encounter 
data capture, to enter information related to changes in 
the patient's condition, and 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the patient data for access by the point of care 
system. 

2. The medical records system of claim 1, further com- 
prising a medication data capture, in data communication 
with the patient data capture and the progress notes, to enter 
medication information for the patient. 

3. The medical records system of claim 1, further com- 
prising a practice guideline for reference to accepted medi- 
cal practices, wherein the practice guideline communicates 
with the patient data capture, the clinical data capture, the 
progress notes and the encounter data capture. 

4. The medical records system of claim 3, further com- 
prising a medication data capture, in data communication 
with the patient data capture, the progress notes and the 
practice guideline, to enter medication information for the 
patient. 

5. A medical records system, comprising: 

a point of care system to capture patient data at a point of 
care; and 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the patient data for access by the point of care 
system, wherein the patient data repository comprises a 
server computer having access to patient data stored in 
a relational database that accepts SQL data queries. 

6. A medical records system, comprising: 

a point of care system to capture patient data at a point of 
care; and 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the patient data for access by the point of care 
system, wherein the patient data repository comprises a 
server computer having access to patient data stored in 
a relational database that is ODBC compatible. 

7. A medical records system, comprising: 

a point of care system to capture patient data at a point of 
care; and 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the patient data for access by the point of care 
system, wherein the patient data repository comprises: 
a patient locator having a patient identifier, 
a data manager, in communication with the patient 
locator, to organize patient data for storage and 
retrieval using the patient identifier, and 
a data interface, in communication with the data 
manager, to transmit patient data to external systems 
and to receive patient data from the external systems. 
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8. The medical records system of claim 7, wherein the 
patient data repository further comprises: 

a cache, in communication with the data manager, to 
temporarily store the patient data for retrieval; and 

a data archive, in communication with the cache, to 
permanently store the patient data. 

9. The medical records system of claim 8, wherein the 
cache is located on a server computer. 

10. The medical records system of claim 8, wherein the 
cache is distributed across a computer network. 

11. The medical records system of claim 8, wherein the 
data archive comprises a jukebox having at least one storage 
device. 

12. The medical records system of claim 11, wherein the 
at least one storage device is a recordable optical disk. 

13. The medical records system of claim 11, wherein the 
at least one storage device is a magnetic disk drive. 

14. The medical records system of claim 7, wherein the 
data interface comprises: 

a communication interface to send and receive patient 
data from external systems; 

an interface manager, in communication with the com- 
munication interface, to set the communication inter- 
face for either transmission or receipt of the patient data 
from the external systems; and 

a data handler, in communication with the interface 
manager and with the communication interface, to 
convert selected patient data into a selected data format. 

15. A medical records system, comprising: 

a point of care system to capture patient data at a point of 
care; 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the patient data for access by the point of care 
system; and 

a reference database in communication with the point of 
care system. 

16. The medical records system of claim 15, wherein the 
reference database comprises: 

a diagnosis module having diagnosis codes indicative of 
a condition of a patient; 

a procedure module, in communication with the diagnosis 
module, having procedure codes indicative of a treat- 
ment to administer to the patient; and 

a medication manager, in communication with the diag- 
nosis module and with the procedure module, having 
information on medication to administer to the patient. 

17. A medical records system, comprising: 

a point of care system to capture patient data at a point of 
care; 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the patient data for access by the point of care 
system; and 

a legacy data system in communication with the patient 
data repository. 

18. The medical records system of claim 17, wherein the 
legacy data system comprises: 

a data source having patient data; and 

a converter, in communication with the data source, to 

convert the patient data into a selected format for 

transfer to the patient data repository. 

19. The medical records system of claim 18, wherein the 
data source comprises physical data. 
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20. The medical records system of claim 18, wherein the 
data source 20 comprises a mainframe computer having 
electronically stored patient data. 

21. The medical records system of claim 18, wherein the 
converter comprises a scanner. 

22. A medical records system, comprising: 

a point of care system to capture patient data at a point of 
care wherein the point of care system provides for 
annotation of the patient data; and 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the patient data for access by the point of care 
system. 

23. The medical records system of claim 22, wherein the 
annotation acknowledges review of the patient data. 

24. The medical records system of claim 22, wherein the 
annotation includes instructions for patient care. 

25. The medical records system of claim 22, wherein the 
annotation indicates approval. 

26. A medical records system, comprising: 

a point of care system to capture data at a point of care; 
and 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the data in a patient record for access by the 
point of care system, wherein the data comprises inter- 
face files and wherein the patient record includes, 
a patient identifier, and 

at least one data structure including the patient identi- 
fier and the data. 

27. A medical records system, comprising: 

a point of care system to capture data at a point of care; 
and 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the data in a patient record for access by the 
point of care system, wherein the data comprises legacy 
files and wherein the patient record includes, 
a patient identifier, and 

at least one data structure including the patient identi- 
fier and the data. 

28. A method of using an electronic medical records 
system, comprising the steps of: 

capturing patient data electronically at the point of care; 
organizing the patient data so as to form a patient record; 
filing the patient record; and 

retrieving the patient record to access the patient data for 
use in the care of a patient. 

29. The method of claim 28, wherein the step of retrieving 
the patient record includes annotating the patient data. 

30. The method of claim 28, further comprising the step 
of evaluating the patient data so as to make a diagnosis. 

31. The method of claim 30, wherein the step of evalu- 
ating the patient data comprises consulting a diagnosis 
module to review diagnosis information. 

32. The method of claim 30, further comprising the step 
of prescribing a medication. 

33. The method of claim 32, wherein the step of prescrib- 
ing a medication comprises consulting a medication man- 
ager to review medication information. 

34. The method of claim 30, further comprising the step 
of administering a treatment. 

35. The method of claim 34, wherein the step of admin- 
istering a treatment comprises consulting a procedure mod- 
ule to review procedures to administer the treatment. 
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36. A method of retrieving patient data in an electronic 42. The method of claim 41, wherein the threshold 
medical records system having a patient data repository, comprises a selected time and the status comprises the 
comprising the steps of: duration of time the data has been in the cache. 

obtaining a patient identifier; 43. The method of claim 41, wherein the threshold 

locating a patient record corresponding to the patient 5 comprises a selected portion of the storage capacity of the 

identifier in the patient data repository; cache and the status comprises the filled portion of the 

determining the location of the patient data within the cache. 

patient record. 44. A method of communicating with an external source 

37. The method of claim 36, further comprising the step JQ having an interface to an electronic medical records system, 
of delivering the patient data. comprising the steps of: 

38. The method of claim 36, wherein the patient data _ P 

repository includes a cache and a data archive. findlD S an interface for the external source; 

39. The method of claim 38, further comprising the step connecting to the external source using the interface; and 
of delivering the patient data when the patient data is located J5 converting patient data for transfer between the external 
in the cache. source and the electronic medical records system. 

^40. The method of claim 38, further comprising the steps 45 ^ melhod of ^ u whm[n ^ slep of convert . 

0 " t ing patient data for transfer comprises converting patient 

moving the patient data from the data archive when the data for trans f er fj- om me electronic medical records system 

patient data is not located in the cache; and 20 tQ lhe exteraal 

delivering the patient data. 46. The method of claim 44, wherein the step of convert- 

41. A method of managing a patient data repository j ng pat j cnt data for traasfer comprises converting patient 

having a cache and a data archive, comprising the steps of: dala for trans f er fr om the external source to the electronic 

monitoring a status of data within the cache; and medical records system, 

moving the data to the data archive when the status 25 

exceeds a threshold. * * * * * 
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Fig 1: Element-Based User Process, with Mechanisms Identified 
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Fig 2: Opportunities for Data Input in Element-Based Process 



Printed 7/8/2005 



Page 2 



DetaiLogic 



DetaiLogic 




User B: Decided on Products, Wants Confirmation 



Record User's Input 

• Basic Project Information 

• Distinct Project Areas 

• List of Needed Details 



Record Performance Criteria * 



Record User-Selected Products 



Record Corresponding Elements (Assemblies, Subassys) 



User A 
Accepts 




User A or B Rejects 



UserB 
Accepts 



Assess Performance 



Output Performance Assessmt 




User 
Confirms 
Assessment/ Rejects 



Accepts 



o 
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Fig 3: Product-Based User Process (Valid for User Types A and B only) 
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DetaiLogic Basic Mechanisms 

1 . User inputs: All Users 

a. Basic Data: Project Name, Zip Code, Jurisdiction, Status (new or renovation), 
Size, Fire Suppression, Street Frontage, and Program (occupancy type or use 
group) 

b. Users' preferred path from 3 alternates 

i. User Type A: Make all selections 

ii. User Type B: Make selections but have DetaiLogic confirm performance 

iii. User Type C: Ask DetaiLogic to make selections 

c. Users' preferred focus from 2 alternates 

i. Focus E: User picks elements 

ii. Focus P: User picks products 

d. Users' designation of Project Areas, subsets within the project that share a 
common set of elements (styles, forms, assemblies, subassemblies, materials, and 
treatments), and therefore a common set of details and specifications. Some 
projects may have only one such area, others may have a few or even many such 
areas. Users input a name for each area and provide a brief description of what 
makes it distinctive. The name is used in subsequent screens to identify the part of 
the project currently being processed. 

e. Users' complete list of needed details (e.g.: parapets or eaves) based on the basic 
configuration of the design in each Project Area. Users simply pick detail types 
from an offered list. 

2. DetaiLogic Preliminary: All Users 

a. From inputted Zip Code, Jurisdiction, and Status: 
i. Look up applicable building codes 

b. From inputted Size (area and height), Fire Suppression, and Street Frontage 

i. Suggest possible Construction Classifications 

ii. Ask Users to pick one. 

c. From selected Construction Classification and inputted Occupancy Type 

i. Look up applicable provisions in applicable Building Codes. 

ii. Use them to narrow the range of qualified elements (assemblies, materials, 
etc.). 

iii. Display only qualified elements in subsequent screens. 

3. DetaiLogic Intermediate 

a. User A Focus E (Element) 

i. Ask Users to choose element sets for each Area, including choices for Forms, 
Styles, Assemblies, Subassemblies, Materials, and Treatments. To continue 
with this sequence, Users must specify all elements at all levels. Those who 
don't will be directed to the User C approach and DetaiLogic will suggest 
choices for the missing elements. Under that scenario, Users can choose any 
number of elements, in any order, and leave blanks for any for which they'd 
like suggestions from DetaiLogic. All selections made are saved for use in 
ensuing steps. 
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ii. Search products database to find products whose performance fulfills the 
requested criteria. List them for Users, ranked in order of closeness of match. 
Users determine how many suggestions they want presented. 

iii. Ask User to identify products to be used from those suggested. If any are 
accepted, replace generic data with proprietary data. Where no product is 
selected for a particular element or group of elements, DetaiLogic will 
proceed using generic information. 

b. User A Focus P (Product) 

i. Ask User to choose product sets for each Area and for each Subassembly 
within each area. To continue with this sequence, Users must specify all 
products. Those who don't will be directed to the User C approach where 
they will identify performance criteria and let DetaiLogic suggest choices for 
elements related to the missing products. Any products that have been 
selected are saved for use in ensuing steps. 

ii. Ask Users to identify specific Assembly and Subassembly applications for 
each of the selected products. For example, a user might pick "Armstrong 
foil-faced R-19 fiberglass batts" and then identify it as applying to the 
thermal separation subassembly and to both enclosing wall and soffit 
assemblies. 

iii. Show to Users, get confirmation 

c. User B Focus E 

i. Present Users with a list of performance categories. 

ii. Ask Users to identify performance criteria for each category that they feel is 
germane. Users can identify as many or as few criteria as they like. 
DetaiLogic will ask Users to repeat the process for as many elements as the 
User cares to establish performance criteria. DetaiLogic will ask for: 

1 . The relative priority of each category of performance 

2. A qualitative range of performance required 

3. A quantitative range of performance required, including 

a. A quantity 

b. A unit of measure 

c. A standard test for measuring performance, including 

i. The test designation 

ii. The publisher of the test 

iii. The version of the test 

iii. Where only qualitative criteria are identified, preventing DetaiLogic from 
conducting an objective search of its database, DetaiLogic can make the list 
available to manufacturers if so requested by Users. 

iv. Ask Users to choose element sets for each Area, including choices for Forms, 
Styles, Assemblies, Subassemblies, Materials, and Treatments. To continue 
with this sequence, Users must specify all elements at all levels. Those who 
don't will be directed to the User C approach and DetaiLogic will suggest 
choices for any missing elements. Under that scenario, Users can choose any 
number of elements, in any order, and leave blanks for any for which they'd 
like suggestions from DetaiLogic. All selections made are saved for use in 
ensuing steps. 
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v. Compile performance data for each of the chosen element sets. For example, 
for all of the subassemblies in a given assembly, add the requested R-values, 
the requested dollar costs, the likely weight, the requested STC rating, etc. 
Where a User requests values for assemblies as a whole, DetaiLogic will 
tabulate such values along with the totaled values on the constituent 
subassemblies to be able to report any discrepancies. 

vi. Show results of performance compilation to Users, ask for confirmation. If 
rejected, Users can either revise the performance criteria requested or select a 
different combination of elements. If accepted, continue. 

vii. Search products database to find products whose performance fulfills the 
requested criteria. List them for Users, ranked in order of closeness of match. 
Users determine how many suggestions they want presented. 

viii. Ask User to identify products to be used from those suggested. If any are 
accepted, replace generic data with proprietary data. Where no product is 
selected for a particular element or group of elements, DetaiLogic will 
proceed using generic information. 

d. User B Focus P 

i. Use a hybrid of the process outlined for User B Focus E and the process 
outlined for User A Focus P. 

e. User C Focus E (Focus P is not an option) 

i. Use the process for User B Focus E, steps 3.c.i through 3.c.iii. 

ii. Search the DetaiLogic database of generic elements to find Forms, Styles, 
Assemblies, Subassemblies, Materials, and Treatments that meet the 
requested performance criteria. 

iii. Show the found elements to Users, ranked within each group by degree of 
fulfillment of requested criteria 

iv. Ask Users to choose elements from list presented. Where none of the found 
elements is acceptable, Users can go back to step 3.c.ii and modify the 
requested performance criteria. 

v. Continue with the process for User B Focus E, steps 3.c.v through 3.c.viii. 
4. DetaiLogic Final: All Users 

a. Build Detail 

i. Compile subassemblies and products into assemblies 

1 . Search the database for the CAD drawing files that correspond to the 
selected subassemblies or products. Conduct the search using imbedded 
attributes that match the performance criteria categories and listings. 
Format all drawings in the database in a standard way to make each 
drawing interchangeable with all other drawings showing subassemblies 
or products of the same type. 

a. Draw each with a standard element thickness, ready to be stretched to 
the specific thickness needed. 

b. Draw each for a standard set of conditions, so that each drawing is 
actually a series of drawings depicting 

i. internal conditions such as inside corners, outside corners, angles 
and curves, 
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ii. termination conditions such as copings, casings, fascias, eaves, 
sills, heads, and jambs, 

iii. interruption conditions such as joints and penetrations, and 

iv. transfer conditions such as rigid, pinned, and roller connections. 

c. Draw each with an embedded set of insertion points at strategic 
locations. For example, draw support subassemblies with unique 
insertions points embedded at top and bottom inside and outside edges, 
the places where interior and exterior surface subassemblies would be 
attached. 

d. Format drawings in compliance with the latest release of the National 
CAD Standard for layering conventions, line weights, symbols, etc. 

2. Adjust each series of drawings so that the thickness between faces 
corresponds to the subassembly thickness selected. This would use a 
technique akin to the AutoCAD "stretch" command and, like all of the 
processes not identified as being taken by Users, would be accomplished 
with no direct action by Users. 

3. Gather the individual files for all of the subassemblies that constitute a 
single assembly. Align the individual thickness-adjusted subassembly 
drawings using their corresponding insertion points to create a series of 
assembly drawings for each of the specific conditions described above in 
4.a.i.l.b. 

4. Save the compiled set of drawings as a new file representing the selected 
assembly. 

ii. Compile Assemblies into Connections 

1 . Background: Each of the details previously identified by Users as being 
needed (in l.e above) is composed of a series of connections. DetaiLogic 
knows which connections are needed to make each of those details, 
enabling the next group of steps. 

2. Gather all of the individual files that contain drawings of the assembly 
conditions needed for one of the connections. 

3. Merge the assembly condition drawings into a single connection drawing 
using standard insertion points as noted above in 4.a.i.l.c. 

4. Show compiled connections to Users. If several options meet a similar 
number of performance criteria, show them all. 

5. Ask User to choose one. If all proposed connections are rejected, take 
Users back in the process to make different selections. 

iii. Compile connections into details 

1. Background: Since DetaiLogic deduced the needed connections from the 
requested details, going back from connections to details requires only 
reassembly. 

2. Gather all of the individual files that contain drawings of the connections 
needed for one of the details. 

3. Merge the connection drawings into a single detail drawing using standard 
insertion points as noted above in 4.a.i.l.c. 

4. Show compiled details to Users. At this point, only one detail will likely 
work. 
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5. Ask User to accept the proposed detail. If it is rejected, take Users back in 
the process to make different selections. 

b. Compile element specifications into a comprehensive specification. 

i. Search the database for the specifications files that correspond to the selected 
subassemblies or products. Conduct the search using imbedded attributes that 
match the performance criteria categories and listings. Format all text using 
CSI SectionFormat standards and conventions. 

ii. Show to Users, get confirmation 

c. Repeat 4.a and 4.b for all details until the entire scope of drawings and 
specifications is created. 

d. Repeat entire process for other Areas. 

e. When drawings and specifications for all Areas are created, ask Users for their 
preferred format of output. 

f. Ask the User to take one of two actions: 

i. Authorize DetaiLogic to output the drawings and specs to the Users' 
computer. The User can then compile them manually into a single set of 
drawings and a single specifications book. 

ii. Authorize DetaiLogic to take over 

1 . Arrange the drawings into sheets guided by the National CAD Standard 
and arranged by Areas where appropriate and produce a new compiled set. 

2. Collate the specifications into Sections and produce a new compiled set. 

g. Beyond DetaiLogic, Users will further customize the documents and check them 
for quality before release. 

5. Non-sequential processes 

a. Progress: At any time, DetaiLogic Users can check their progress by consulting a 
chart of assemblies on which DetaiLogic will indicate that specific subassemblies 
or products have been selected. By clicking on each indicator, Users can display a 
thumbnail graphic of the associated subassembly or product. Progress can be 
gauged by noting the percentage of needed subassemblies or products that have 
been selected. 

b. Help: DetaiLogic contains hundreds of generic data sheets that provide 
information to guide Users in making selections between alternative elements 
including styles, forms, assemblies, subassemblies, materials, treatments, 
connections, and details. Context-sensitive help files can be accessed at any time 
by DetaiLogic Users. 



DetaiLogic Extended Mechanisms 

1 . "What If Analyses: Valid for User Types B and C only, since process requires 
identification of performance criteria. 

a. Preliminary: Take Users through basic DetaiLogic mechanisms outlined above, 
all the way through the end of Step 3, when all elements and products for a 
particular Area are tentatively selected. 
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b. Intermediate: Allow Users to change any number of performance criteria, 
elements, and/or products, and then resubmit the new combination to the search 
process. 

c. Final: When an acceptable new combination is proposed by DetaiLogic, one that 
complies with the revised list of performance criteria, elements, and/or products, 
send it through the Final process outlined above in Step 4. This can be done any 
time and as many times as needed. 

2. Manufacturer and Trade Association Processes: Providing data for use by DetaiLogic 
Users 

a. Obtain data formatting guidelines form DetaiLogic for performance criteria, 
drawings, and specifications. 

b. Prepare data in conformance with guidelines 

c. Submit data to DetaiLogic for review 

d. Obtain numeric tags from DetaiLogic that links data with DetaiLogic network. 

e. Affix virtual numeric tags to data so it can be accessed by DetaiLogic subscribers 
as part of extended DetaiLogic database. 
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From: Barry D. Yatt [barry.yatt@verizon.net] 
Sent: Thursday, July 07, 2005 10:24 PM 
To: Thomas Bergert 
Subject: Further patent documentation 

Hi Tom, 

Attached is my first stab at charts and a flow description. What else should I be doing? Send comments. 

I hope to hear back from John tomorrow with a contract that we can execute. I leave Saturday morning and will 
not be back until Saturday night, July 23 except for all day on Tuesday, July 12 and the evening of Saturday, July 
16. 
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Barry 
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ABSTRACT 



An e-commerce exchange for gathering and managing a 
widely distributed inventory of blood, tissue and other 
samples for the biomedical research community and phar- 
maceutical industries worldwide. Samples belonging to reg- 
istered sample providers are entered into a database at a 
central host site which is part of a distributed computer 
network. The samples are tagged by fields to cross reference 
the samples according to a number of specified criteria. 
Registered buyers search the database according to desired 
criteria. When the criteria of the search request matches the 
criteria specified for a particular sample, the central host site 
approves and supervises transfer of the particular sample 
from the supplier to the requesting buyer. Additionally, when 
the search request is not successful, there being no matching 
sample, the buyer may enter the requested sample criteria 
onto a wish list. A sample supplier having an unlisted sample 
meeting the criteria of an biological sample on the wish list 
may enter the sample into the database and the central host 
site will notify the buyer of sample availability and prompt 
transfer to the buyer. 

19 Claims, 11 Drawing Sheets 
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WEB-INTEGRATED INVENTORY 
MANAGEMENT SYSTEM AND METHOD 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention is related to the field of on-line 
computing and, more particularly, to a computer-based sys- 
tem and method for managing a dynamic and widely dis- 
tributed inventory of biological samples or other perishable 
items and materials. 

2. Description of the Related Art 

To date, scientists and clinical researchers have spent 
valuable time and resources searching for the biological 
samples, such as blood, tissue, serum, plasma, bodily fluids, 
etc., that are essential to allow them to research, diagnose 
and help expedite cures for the world's vast number of 
diseases and other medical conditions. 

Research sample needs are currently only partially ful- 
filled and are conducted by telephone, facsimile and time 
consuming networking between sample providers such as 
doctors, hospitals, laboratories, collection agencies and 
research product brokers. Using current methods, it often 
takes weeks to obtain even basic research samples; the 
procurement of rare samples can take months and even 
years, if they can be obtained at all. 

Accordingly, there is an unmet need and increasing 
demand in the biomedical/pharmaceutical industry for 
accessible research products and related data. 

SUMMARY OF THE INVENTION 

In view of the foregoing, one object of the present 
invention is to overcome the difficulty in obtaining the 
biological samples necessary for research and other medical 
developments through a web-integrated inventory manage- 
ment system. 

Another object of the invention is a sophisticated, yet 
simple to operate, one stop e-commerce exchange. 

A further object of the invention is a search engine 
capable of searching for and locating samples according to 
a multitude of parameters which could not previously be 
designated on sample inventories. 

A still further object of the invention is an inventory 
management system allowing sample providers to post their 
inventory in seconds and obtain worldwide exposure. 

Yet another object of the invention is an on-line inventory 
management system that gives biomedical companies the 
ability to manage their inventories from designated and 
secure shelf space accessible to them through any web- 
enabled computer. 

Another object of the invention is an integrated system for 
searching, finding, purchasing and receiving biological 
samples in a convenient, cost-effective and timely manner. 

In accordance with this and other objects, the present 
invention is directed to a system and method for use with a 
distributed computer network, such as the Internet, that 
enables researchers, and others, to search for and purchase 
samples of biological material according to specified crite- 
ria. Through the present invention, sample buyers and sellers 
are brought together to a degree not previously available, 
increasing the value of the samples, both in terms of 
purchase price and research contribution. 

The wcb-intcgrated inventory management (W1M) sys- 
tem of the present invention comprises a central host site 
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having a search engine for accessing at least one central host 
site database. Each sample provider wishing to subscribe to 
the WIM system provides the central host site with infor- 
mation describing an inventory of biological samples 
5 belonging to the sample provider. Each biological sample is 
tagged according to a plurality of fields. The fields identify 
the sample by specifying various criteria for or parameters 
of the sample. Tagging the samples by field essentially 
indexes the samples, cross-referencing them according to 
10 the specified parameters. The field information associated 
with each sample is then entered into the central host site 
database. 

As the sample provider obtains additional samples, the 
sample provider can key in these later samples by hand, 
15 tagging the fields as desired. Alternatively, the sample 
provider can send the sample information to the central host 
site for tagging and entry of the sample into the central host 
site database. 

By subscribing to the WIM system, sample providers may 
20 be relieved of the need to manage their own inventory and 
can instead choose to rely upon the monitoring and updating 
services provided by the WIM system. Each subscribing 
sample provider is afforded a designated password-protected 
"shelf space" with which they can do as they wish, providing 
25 them with what is essentially a worldwide storefront win- 
dow and at very low cost to them. Because the inventory 
management system is web integrated, sample providers can 
access their inventories from any location having Internet 
access. 

30 

Researchers and other sample buyers search the WIM 
system database by specifying desired criteria by field. The 
WIM search engine searches the central web site database 
for matches to the request according to the information 
provided in the tagged fields. If a sample matching the 
35 request is not available, the buyer can place the request on 
a listing of desired but currently unavailable samples, i.e!, a 
wish list. Responsive to a posting on the wish list, the WIM 
host site automatically generates email messages to sub- 
scribing sample providers, informing the sample providers 
40 of the desired criteria and that a prospective buyer has posted 
a request to purchase a sample meeting these criteria. 

If a sample provider has, or subsequently obtains, a 
sample matching the criteria of a wish list item, the sample 
45 may be added to that provider's inventory as a new sample. 
The WIM host site automatically and routinely compares 
existing inventory sample data to items listed on the wish 
list. Upon detecting a match between the new sample and a 
specific wish list request item, the WIM host site generates 
50 an email notifying the buyer that a sample meeting his or her 
wish list criteria is available, and prompts purchase. 

If a sample meeting all the specified criteria is available, 
the buying sequence may be initiated. This sequence is 
commenced by the buyer requesting availability of the 
55 sample. Responsive to this request, the WIM host site 
generates an email to the appropriate sample provider. The 
email includes a hyperlink to the host site. The sample 
provider confirms sample availability by clicking on the 
hyperlink and then checking which samples are available. 
60 The WIM host site then generates and sends an email to the 
buyer identifying the confirmed samples. 

To purchase, the buyer selects a form of purchase, e.g., 
purchase order, wire, credit card, etc. Upon approval of the 
order by the central host site, a confirmation is sent to the 
65 buyer and to the sample provider, and the order is shipped. 
These and other objects of the invention, as well as many 
of the intended advantages thereof, will become more 
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readily apparent when reference is made to the following FIG. 2 is an illustrative example of the site architecture, 

description taken in conjunction with the accompanying As shown in this example, web browsers provide the user 

drawings. interface, PHP3 scripts provide business logic, and a 

MySQL database provides data storage. A set of helper tasks 

BRIEF DESCRIPTION OF THE DRAWINGS 5 0 r daemons written in Perl may be run on a regular basis to 

FIG. 1 is a block diagram of the web-integrated inventory regenerate indices, update database flags, backup databases, 

management (WIM) svstem in accordance with the present elc " 85 scheduled by a Unix host system. Such a Unix 

invention- system may be provided in a virtual server environment. 

FIG. 2 is a diagram of a site architecture in accordance in 3 Provides an illustrative overview of the host site 

with one embodiment of the present invention; 10 and lts ^nte. As shown, in preferred embodiment the 

- c t r , host site includes a static site area 20, a user area 212, and 

FIG. 3 is an ^strative overview of the contents of the aQ adminislrator area 2 U. The static area may be controlled 

host Slte of FIG ' 1; t using a main template script, e.g., index.php3. Although 

FIG. 4 is a representative arrangement of tables within the generated using a script, the area is referred to as static 

database of FIG. 1; 15 because it makes no use of the database. 

FIG. 5 is a flowchart of the process of sample provider a user.php3 script is the gateway to the dynamic part of 

registration within the WIM system of FIG. 1; the system. This script provides log-on services as well as 

FIG. 6 is an illustrative data entry screen for adding a new the menu structure for the user area 212. Users belonging to 

sample, in accordance with the present invention, the administrative group are able to enter the administrative 

FIG. 7 is a flowchart summarizing buyer registration, 20 area 214, which is representatively controlled through 

sample search and sample purchase, in accordance with the admin.php3 scripts. 

present invention; Upon logging onto the WIM host site 12, the accessing 

FIG. 8 is a more detailed flowchart of the sample search * S reeted ™ lh a " Home " P a 8 e which » the static 

process of FIG. 7; area ^10. The "Home" page is the gateway to the site and 

™^ n . ' . -I i n u . * 4 . r 25 provides the accessing user with an overview of the site's 

FIG. 9 is a more detailed flowchart of the entrv of an item r .. , . . c , . to , , ~, - . . 

. 4 . . , , . , - * available information and procedures. Other pages or folders 

to the wish list process of FIG. 7; , , . , , , . r . , 4 K ,■ 4 , 

r may be selected by clicking on the visible tabs and/or listed 

FIG. 10 is a flowchart summarizing sample provider Hnks as would 5e knowo by one of skill in the art Pages may 

searching of the wish list, in accordance with the present include? among others: « About Us » which suramarizes 

invention. information pertaining to the sponsoring host site; "Q & A", 

FIG. 11 is more detailed flowchart of the purchasing which presents frequently asked questions and the answers 

process of FIG. 7; and thereto; "Site Map", which summarizes the contents of the 

FIG. 12 is an illustrative data entry screen for the sample site with a listing of available page, that can be accessed by 

searching process of FIG. 8. clicking thereon, and also provides a listing of support and 

35 purchasing information; "Contact Us", which provides 

DETAILED DESCRIPTION OF THE address, phone and computer contact information of the host 

PREFERRED EMBODIMENTS s j te S po nsor} as we n as promotional information; and. 

In describing a preferred embodiment of the invention "Register", which offers the accessing user the options of 

illustrated in the drawings, specific terminology will be 4Q choosing to register as a sample provider, as a researcher, or • 

resorted to for the sake of clarity. However, the invention is as a guest. Each page, once accessed, contains multiple links 

not intended to be limited to the specific terms so selected, lo other pages, as is known to those of skill in the art. 

and it is to be understood that each specific term includes all The layout of the web pages can also accommodate 

technical equivalents which operate in a similar manner to advertising, particularly as pertaining to products and ser- 

accomplish a similar purpose. 45 vices relating to the biological and medical fields. Adver- 

As illustratively shown in FIG. 1, the present invention is tising may be incorporated throughout the pages or may be 

directed to a web-integrated inventory management (WIM) accessed through an advertising page or hyperlink, as 

system, generally designated by the reference numeral 10. desired. This option provides an excellent opportunity for 

The system includes a central WIM host site 12 having a product and service providers in the clinical research and 

search engine 13 for accessing a database 14. Sample 50 related medical fields to target consumers having an interest 

providers 16 and buyers 18 access the WIM host site 12 in these specialized product and service areas, 

through a distributed computer network such as the Internet. All the data in the host site is stored in the database 14, 

The WIM host site 12 also has links for the financial which may be embodied as one or more MySQL databases, 

transaction 20 necessary to complete inventory transfer. The database includes a plurality of tables; a representative 

The WIM system 10 provides means for buyers 18 and 55 arrangement of such tables for a preferred embodiment is 

sample providers 16 to match their needs and available provided in FIG. 4. Several other tables for various purposes 

products, respectively. Registered sample providers and are also maintained, and the tables are regenerated on a 

buyers may each initiate searches of the database 14 of the periodic basis. 

WIM host site 12 using the search engine 13. The result is In the embodiment shown in FIG. 4, all tables in the 

maximum utilization of the available samples, and the 60 database have a unique identifier field, called "id". This field 

enhancement of research and other clinical efforts to cure is used to link related tables. For example, the user table has 

medical conditions. a field called account_id that is related to the account table 

The WIM host site 12 is prefer ably embodied as a web id field. The seller_id and the buyer_id fields refer to the 

site accessible over the Internet. As such a site, the host site account id of the sample provider and buyer, respectively, 

may be configure in a number of ways, as would be known 65 As shown in FIG. 4, the host site centers on the account 

by persons of ordinary skill in the art; the following general table. This table contains all the information pertaining to a 

overview of the site is for illustrative purposes only. particular account. An account can have one or more users, 
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samples, orders and wish list entries. The main user file of 
the account table indicates the users to which official cor- 
respondence will be sent. 

The user table contains the users of the system. A user has 
one shopping cart, and belongs to one account. The sample 
table contains information about the samples. A sample 
belongs to one account. The results table contains specific 
information about products, drugs, or diagnosis associated 
with a sample. A sample can contain zero or more results. 

Each user has an independent shopping carl, which is 
stored in the cart table. Researchers are allowed to search the 
system and add samples to the cart. For each item in the 
shopping cart, the user id of the buyer, the id of the sample, 
and the desired amount is stored in the table. Once the buyer 
wishes to place an order, the system creates an entry to the 
orders table, and the samples in the shopping cart are 
transferred to the order__item table. From this point on, the 
order and associated samples are tracked from the order_ 
item table. 

The database 14 resident at the WIM host site 12 contains 
an extensive inventory of biological samples belonging to a 
plurality of sample providers 16. This information is main- 
tained in the sample table. In order to list sample inventory 
through the host site, each sample provider 16 must first 
register with the WIM system. This registration process is 
set forth in FIG. 5. 

A sample provider wishing to register first accesses the 
WIM host site 12 using a web-enabled computer. In this 
document, "web-enabled computer" refers to a computer 
having all the necessary hardware and software, e.g., 
modem, browser, etc., correctly installed as would be known 
by one of skill in the art so as to enable the computer to be 
linked to a distributed computer network such as the Internet 
for access to and exchange of electronic information. 

As used herein, a "web-enabled computer" is also under- 
stood to be enabled for electronic messaging such as trans- 
mission and receipt of email communications. However, it 
would be possible to implement the present invention with- 
out the use of email, relying instead on facsimile 
transmission, for example; such alternative embodiments are 
also covered by the present invention. However, in the 
preferred embodiments, email communication is utilized. 

Upon accessing the WIM host site 12, the sample provider 
16 selects the "Register" page 22 as an option from the 
"Home" page. The register option may be resident on a page 
accessed from the "Home" page, may be a selection button 
on the "Home" page, or may be made accessible to the 
sample provider in any other manner as would be known by 
those of skill in the art. 

Upon access to the "Register" page, the sample provider 
selects the option to register as a sample provider and enters 
pertinent registration information 24. Such information 
should include at least the name of the organization, address 
and phone, URL, and email address. The registration infor- 
mation also requires entry of one of a CLIA number, an FDA 
registration number or a medical license number. (The CLIA 
number refers to a state license issued to laboratories under 
the Clinical Lab Improvement Act.) 

Following entry of the administrative information, the 
sample provider enters a user name and password 26. During 
subsequent contacts with the WIM host site, the sample 
provider uses the specified user name and password. If the 
sample provider forgets the password, the WIM host site will 
prompt entry of the email address as provided during 
registration. The system will then send an email to the 
registered organization identifying the correct user name and 
password. 
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Once registered, the sample provider provides its inven- 
tory 28 to the WIM host site 12. Each sample is tagged and 
entered 30 into the database 14 of available samples. 
Samples are tagged by field to cross reference them in 
5 accordance with a variety of criteria. Sample fields may also 
be tagged for other purposes. Once the samples have been 
entered, sample providers may then manage their inventory 
through the WIM system 32. 
The inventory management function of the present inven- 
10 tion supports both sample providers wishing to list inventory 
for sale as well as companies with biological samples who 
desire inventory management capabilities but who do not 
have inventory they wish to sell. With particular focus on 
this latter group, in accordance with the WIM system of the 
present invention, such companies may license WIM system 
15 software. In a preferred embodiment, a copy of the WIM 
system software is loaded on one or more alternative secure 
web sites, separate from the WIM host site, and set up 
specifically for such inventory management support. Mul- 
tiple inventories may, of course, be maintained at a single 
20 alternative site, with particular inventories accessed using a 
specific provider identification number or other code. 
Through such an alternative secure web site, licensed com- 
panies are able to access their inventory from any web- 
enabled computer, regardless of location. This capability 
25 also provides companies having a number of distributed 
offices, each of which may have a different internal com- 
puter system, with a centralized and unified means of 
tracking their company-wide in-house inventory that is 
simply not available in the prior art. 
30 In an alternative embodiment, non-salable or maintenance 
inventory may be placed into the WIM host site database, 
but tagged to be non-viewable to prevent access by those 
parties searching the system to purchase samples. However, 
the preferred embodiment is to maintain sales inventory and 
35 maintenance inventory through separate WIM system sites. 
When used with specificity herein, "maintenance inventory" 
refers to biological inventory not offered for sale but being 
managed in accordance with the WIM system of the present 
invention. When not specifically identified as maintenance 
40 inventory, references to "inventory" are intended to include 
all kinds of inventory, whether being offered for sale or not. 

As part of the inventory management function, whether 
through the WIM host site 12 or through an alternative web 
site supporting maintenance inventory management, the 
45 present invention further includes a bar coding capability for 
sample tracking. Through the WIM host site, or alternative 
site, electronic bar codes are provided to subscribing sample 
providers for each of their samples. These bar codes can 
include a range of information, as would be known by 
50 persons of skill in the art. The samples providers can 
download and print these bar codes using their own com- 
puter equipment and affix the resulting bar code labels on 
respective samples. Bar coding the samples enables auto- 
mated sample retrieval and also enables the data identifying 
55 a particular sample to be transferred easily and 
electronically, whether within the sample provider's system 
or to an ultimate buyer of the sample. A buyer receiving a bar 
coded sample can use the information in the bar code to 
download the full record associated with the sample from 
60 the WIM host site, obviating the need to manually reenter 
the data into the buyer's computer. In that sample providers 
and purchasers may be dealing in hundreds of samples, this 
automation has tremendous value both in terms of time 
savings and the assurance of accuracy in sample information 
tracking. 

Sample provider inventory information may be received 
in any number of formats dependent upon the sample 
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provider's particular computer system, including as Inventory provided to the WIM host site through a down- 
examples, spreadsheet, word processing, database, CVS loaded computer file is processed by the WIM host site. This 
comma delimited files, etc. Furthermore, a single sample processing converts the data received from the often pro- 
provider may have multiple offices and, in many cases such prietary systems of sample providers into the centralized 
as when the sample provider represents a merger of 5 system of the present invention using the customized Perl 
companies, each of these offices may use a different com- script just described, or equivalent import technique as 
puter system. Without the present invention, such sample would be known by those of skill in the art. 
providers are virtually unable to search for samples within Smaller inventories or individual samples to be entered 
their own multi-office inventories, there being no common- may be added on-line by the sample provider through the 
ality across their systems and no solution short of installing 10 WIM host site using the "Sample Inventory Management" 
an entirely new system to unify all of their offices. pa ge, as is described in greater detail hereinafter. In a 

In accordance with the present invention, input data as preferred embodiment, the "Sample Inventory Manage- 

received from sample providers are translated into a ment" page allows the sample provider to add a new sample, 

standardized, web-searchable format. In a preferred edit an existing sample, or list all samples, 

embodiment, input data is exported to a CVS file, which is 15 To add a new s^p]^ tne "Add New Sample" option is 

then parsed by a customized Perl script which imports the selected from the "Sample Inventory Management" page to 

data into the WIM host site database. This represents a bring up the "New Sample" page, shown representatively in 

significant benefit, not only to parties wishing to search the FIG. 6. As with all pages described herein, the "New 

inventory for purchase, for also to the sample provider who Sample" page is exemplary only and is not intended to limit 

needs to know the availability of in-house samples. 20 me on-screen presentation to the particular format shown. 

To describe a sample, the WIM host site database pref- In a preferred embodiment, the "New Sample" page 

erably uses two tables, a.sample table and a results table. The includes links to other pages or folders which may be 

sample table contains a basic set of information that selected by clicking on the visible tabs or linking text, as 

describes a sample and associated patient demographics. At would be known by one of skill in the art. These pages may 

a minimum, all samples contain one entry on the sample 25 include, among others: "Wish List", which allows the user 

table. to add a new wish, search the listed wishes, etc.; "Shopping 

The results table contains an arbitrary number of Cart", which facilitates collection of samples for purchase; 

attributes that can be attached to a record in the sample table "Orders", which summarizes ordering information and pro- 

and which describe additional information about the sample cedures; and "Account Services", which provides a listing of 

beyond that placed on the sample table. In a preferred 30 account activity and status. 

embodiment these attributes identify the search fields, but As may. be seen from FIG. 6, when new samples are 

there does not have to be a direct correspondence between entered into the database 14, each sample is identified 

attributes and search fields. In general terms, the results table according to a plurality of criteria, by fields, which describe 

includes a label and a value. The label identifies an attribute ^ or correlate with the sample. For example, instead of simply 

or product, and the value represents a numerical value adding a sample to the database identified only as "blood", 

associated with the label. For example, the label may be it is much more useful to researchers and others to know that 

"ferritin" with a value of 1.30. The search function performs the blood is of a particular type, came from a person of a 

searches over most of the fields of the sample table and over particular race, demonstrates a particular abnormality, etc. 

the label field on the results table. ^ Therefore, to maximize the utility of each sample, a plurality 

According to the customization of the Perl script, cus- of criteria are specified for each sample, as appropriate to the 

tomer record information is mapped to the host site database sample type. 

data record information. For each field provided in the Representative categories of criteria to be identified for 

customer data, the Perl script typically is configured to new samples as shown in FIG. 6 include sample information 

execute one of three options. The first option is for the script 45 15, patient information 17 and oncology information 19. 

to map the customer sample field to one of the sample table Sample information 15 may include volume, matrix, 

fields. The second option is to append the customer sample laboratory identification number and price. Whether or not 

field to the results table and associate that field with the the sample is a bulk sample may also be checked. Different 

sample table record for that sample. The third option is to or additional sample information may, of course, be used in 

ignore the field. 50 accordance with the present invention. 

As part of the preparation of the customized import script, Sample information may also include the designation of 

all fields that specifically identify the patient are tagged to be particular "products", with the embodiment shown in FIG. 6 

ignored. Fields so tagged are not copied into the WIM host illustrating two product designations, although additional 

site database. By stripping out personalized data, inadvertent product designations may also be included. For each 

disclosure is prevented, patient confidentiality is protected, 55 "product", a product name, value, test outcome and method 

and laboratories are encouraged to list more of their samples of test or test manufacturer may be entered. The "product" 

with the assurance that sensitive fields will not be listed with name may actually be directed to one of three subcategories, 

the sample. namely a product, a diagnosis or a drug, as shown. Addi- 

In a preferred embodiment, only the laboratory identifi- tional details on sample information are included later 

cation (id) number or code given by the sample provider, and 60 herein. 

necessary for proper identification of the sample, is tran- Patient information 17 may include age, gender, race, 

scribed into the host site database. Furthermore, distribution patient ID, patient birth date, field of medicine, medical 

of the laboratory id may be limited to the owner of the record available and doctor certified. Other or additional 

sample and to administrative host site personnel. categories may also be included as appropriate. Additional 

With large inventories, entry of samples is most efficiently 65 details on patient information are included later herein, 

transacted by downloading a computer file of the sample Oncology information 19 may include site, stage, grade 

provider's database of inventory to the WIM host site. and status. Other or additional categories may also be 



ID 


Lab ID 


Matrix 


Volume 


Price 


87888 


12 


Plasma 


0.10 ml 


12.00 per sample 


87276 


21215 


Serum 


12.00 ml 


2.00 per ml 


87294 


32589 


Plasma 


0.20 mi 


12.00 per sample 


87279 


96854 


Serum 


0.40 ml 


4.50 per ml 


87282 


9696 


Heparin 


0.10 ml 


8.00 per ml 
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included as appropriate. Further details on oncology infor- The quick search is a feature of the present invention that 
mation are included later herein. enables the buyer to type in what he or she is looking for 

Upon completion of data entry into the required, as well specifically, without having to enter the range of individual 
as any desired, fields, the sample is added to the inventory search criteria required for a detailed search. To use the 
by clicking on the "Add" button 21. 5 quick search feature, the buyer must enter a minimum of 

To edit an existing sample, the sample provider can three characters representing a word, or part of a word, with 
identify the desired, sample by a sample identification which to search a product, diagnosis or drug field. For 
number, "sample ID"; a laboratory identification number, example, a buyer wishing to find a sample with various types 
"lab ID"; or a patient identification number, "patient ID". of measles as the product would enter "mea". All relevant 
The sample provider designates one of these categories, 10 results would then be located and shown, regardless of 
enters the appropriate number into the designated data entry whether they were input originally as a product, drug or 
field, and clicks on the "Search" button. The desired sample diagnosis. 

is then accessed by the search engine 13 from the database To conduct a detailed search, the buyer enters specified 
14 for editing. criteria describing particular parameters associated with the 

To list all samples, the sample provider can click on the desired sample. Because each sample is cross referenced in 
"List all Samples" option. A list of samples belonging to the accordance with a plurality of attributes, the buyer is able to 
sample provider is displayed. A representative sample list is designate with great specificity, if desired, the particular 
provided in Table I. nature and attributes of the sample desired. This is a capa- 

bility simply not available in the prior art where searching is 
TABLE 1 2Q often limited to designating a matrix or a matrix and one 

other parameter. Using the present invention, by contrast, 
samples may be identified in accordance with multiple 
parameters, with one present embodiment including 18 or 
more. The buyer can also limit the search to samples from 
^ a particular provider. Of course, values for all parameters 
need not be identified when entering or searching for a 
sample. But there are times when having the option of 
searching in accordance with a significant number of param- 
As already discussed, the sample provider may manage ete rs enables highly specific research needs to be very 
inventory with the WIM host site, or alternative site, which particularly and efficiently met. A more detailed description 
is not available for purchase, if desired. However many, if 30 0 f me detailed search process 38 is provided in FIG. 8. 
not most, of the samples within the sample provider's If thc does not locate ^ appropriate sample 40, a 

inventory are typically available to buyers 18 for purchase. negative ^ result fe returned and the buyer may either 
Buyers include researchers and others having need of post the desired item with special procurement 51 or enter 
specified biological samples. For the purposes of this 35 the specified criteria for the desired sample to the wish list 
document, reference to "researchers" may be considered 52. Again, the potential for designating multiple parameters 
synonymous with reference to "buyers" and shall be used to greatly increases the value of these options, 
indicate any party interested purchasing a sample through Special procurcmerjt is a feature of the present invention 
the WIM system 10. mal a u ows tne buyer to post his or her needs in written form 

Buyers 18 register with the WIM host site 12 in order to 4Q without the aid or constraint of designated fields. The buyer 
be able to purchase the samples. The buyer registration ^ provided with a general data entry field and is directed to 
process, along with a general overview of the search and enter in detail the type and amount of samples desired. When 
sample procurement process in accordance with the present data entry is complete, the buyer clicks on a "post request" 
invention is set forth in FIG. 7. button, or other analogous submission means, to post the 

A buyer wishing to register first accesses the WIM host 45 request with the WIM host site. Once posted, the WIM host 
site 12 using a web-enabled computer. In response to the site is notified, and a procurement specialist team is assigned 
"Home" page, the buyer selects the "Register" page 22. The from the host site to facilitate in obtaining the posted 
register option may be resident on a page accessed from the samples. 

"Home" page, may be a selection button on the "Home" Alternatively, the buyer may enter the item into the Wish 
page, or may be made accessible to the buyer in any other 50 List 52. As already mentioned, the wish list is a listing of 
manner as would be known by those of skill in the art. desired, but currently unavailable, samples. The wish list 

Upon access to the "Register" page, the buyer selects the ma y be described as a "wanted" section for use by both 
option to register as a researcher and enters pertinent reg- researchers and sample providers. Researchers use the list to 
istration information 34. Such information should include at post requests for samples that are not presently available in 
least the name of the buying organization, address and 55 the inventory. Researchers can also review their own wish 
phone, URL, and email address. lists and make modifications as needed. A more detailed 

Following entry of the administrative information, the description of entry of items to the wish list is provided in 
buyer enters a user name and password 36. During subse- FIG. 9. The wish list may also be searched by sample 
quent contacts with the WIM host site, the buyer uses the providers, as set forth in greater detail in FIG. 10. 
specified user name and password. If the buyer forgets the 60 If the search does locate an appropriate sample 40, the 
password, the WIM host site 12. will prompt entry of the buyer may request availability of the sample 42. Responsive 
email address as provided during registration. The host site to a request for availability, the WIM host site generates and 
will then send an email to the registered buyer organization sends an email to the appropriate sample provider. If the 
identifying the correct user name and password. request for availability requests availability of samples origi- 

Once registered, thc buyer may search for samples 38. A 65 nating with more than one sample provider, thc WIM host 
sample search may be conducted as a quick search or as a site splits thc request according to sample provider and 
detailed search. sends an email to each provider. 
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Each email identifies the sample or samples of interest allows the buyer to review the inventory sample to deter- 

and provides a hyperlink to the WIM host site. Each mine if the parameters listed represent a sufficient match to 

receiving sample provider clicks on the hyperlink and enable the sample to be of use to the buyer. This posting of 

checks which sample or samples are available using a radio "possible" matches is an alternative embodiment. In the 

button or other equivalent means. To complete confirmation, 5 preferred embodiment, all entered data fields must match a 

the sample provider clicks on a "Confirm", or equivalent, sample in inventory in order for a positive search result to be 

button to send the confirmation to the host site. obtained. If any of the entered data fields does not match a 

Confirmation of sample availability is a valuable aspect of corresponding field in the compared sample in inventory, a 

the present invention due to the fact that sample providers negative search result is obtained. 

may sell their inventory through channels other than the 10 The buyer begins by selecting a "product" 56. More 

WIM host site. When a sale is completed through the WIM specifically, the "product" may be one of three subcategories 

host site, the database is automatically updated, concurrently including a product, a diagnosis or a drug. With reference to 

or within a short time of the sale, removing from the listed the subcategory, product refers to a disease or a condition in 

inventory those samples which are no longer available. But a defined matrix. Other or additional subcategories may also 

since listing inventory with the WIM host site does not 15 be included as appropriate in accordance with the function 

preclude the sample provider from transacting directly with and purpose of the present invention, 

other parties for sale of the samples, an item sold by the The buyer selects one of product, diagnosis or drug by 

sample provider over the counter, for example, will not clicking on the appropriate subcategory. If the buyer is not 

result in an automatic inventory update. Confirming avail- familiar with the search engine, he or she may click on the 

ability enables the buyer to ensure that an advertised sample 20 search button at this stage, and may thereafter narrow the 

is indeed still in the sample provider's inventory. search. 

If the desired sample is not available 44, the WIM host In a preferred embodiment shown in FIG. 12, two fields 

site notifies the buyer 46. If the sample is available 44, the are provided for entry of a product, diagnosis or drug. 

WIM host site automatically generates and sends an email to Having two such fields allows the buyer to search for a 

the buyer confirming sample availability 48. A separate 25 product under two subcategories, e.g., under both product 

email is generated for each sample provider so that if three and drug, both product and diagnosis, or both diagnosis and 

sample providers were polled for available samples, the drug. 

buyer will receive three emails. The buyer may then initiate upon selection of a "product", an A-Z listing of the 

purchase 50 or cancel each order. A more detailed descrip- selected subcategory is displayed and a specific item within 

tion of the purchase process is provided in FIG. 11. that listing may be selected. Clicking on the first letter of the 

Turning now to the search process as summarized in FIG. desired item results in display of a list of items beginning 

8, the buyer begins by logging onto 54 the WIM host site with that letter. To select one of the items, the buyers clicks 

using a web-enabled computer. Following log-on, he or she on the item, which is then automatically entered into the 

is presented with a data entry page for searching samples and 35 "product" name field. 

may initiate a search. A representative sample "Search" page "Product information", which in this document is 

is provided in FIG. 12. intended to include and also refer to information pertaining 

As shown in FIG. 12, the "Search" page includes a quick to products, diagnoses or drugs, as applicable, further 

search feature as well as a plurality of data entry fields, many includes values, testing results and test manufacturer. Values 

of which correspond to the date entry fields shown on the 40 represent a quantitative number for the product, diagnosis or 

"New Sample" page of FIG. 6. Data within these fields drug, and may be entered 58 as absolute values, such as 5, 

define the specified search criteria for a detailed search and 10, 150, etc., or they may be entered 58 as ranges of 

are compared by the search engine to data entered in numbers, such as from 10 to 100. Testing results may be 

corresponding fields in sample inventory, so that detailed designated 60 as either a positive or a negative finding. Test 

searching is conducted on a field by field basis. As previ- 45 result may also specify the qualitative or quantitative analy- 

ously discussed, the quick search feature allows the buyer to sis by a specific manufacturer. Finally, test manufacturer 

search according to a minimum of three characters entered may be selected 62 to obtain results based on a specific type 

into the quick search data entry field. of testing machine or to specify the diagnostic supplier of a 

In the preferred embodiment and using the detailed search specific assay. By clicking on test manufacturer, an A-Z 

option, entry of data into certain data entry fields is required 50 listing of manufacturers is displayed. The manufacturer 

while others may be left blank. Every field containing data selected is automatically entered into the test manufacturer 

is compared with the corresponding field of a sample in field. 

inventory. To achieve a positive search result, i.e., a match The buyer then enters patient information 64. In the 

between the search request and a sample in inventory, all preferred embodiment, patient information includes age, 

entered data fields in the search request must correlate with 55 gender, race, medical record available and doctor certified, 

corresponding data fields in a single sample in inventory. Other or additional categories may also be included as 

Data fields that are left blank in the search request do not appropriate in accordance with the present invention, 

limit the search, i.e., so long as the entered data matches Age may be designated numerically as a specified 

corresponding data field data in a single sample in inventory, number, as less than a specified number, as greater than a 

the fact that the single sample in inventory may have data 50 specified number, or as within a specified range. Age may 

entered in data fields corresponding to the blank fields does also be entered more generally as "low" or "high". Gender 

not prevent a positive search result. and race have pull -down menus with available selections 

The present invention may also be embodied such that listed, 

required data fields must contain corresponding data Medical record available allows the buyer to limit the 

between the search request and the inventory sample, while 65 search to results which have medical records available, 

data fields that arc not required will not prevent posting of Doctor certified allows the sample provider to limit the 

a "possible" match. The posting of a "possible" match search to results which have been certified by a physician. 
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The buyer then enters oncology parameters 66. These may The steps to be taken when adding an item to the wish list 
include site, stage, grade and status. The WIM search 52 are depicted in FIG. 9. The process begins by selecting 
procedure may also be configured to include other or addi- the "Wish List" page 116 and then selecting the "Add a New 
tional parameters as appropriate. Wish" page 118. The "Add a New Wish" page is a data entry 
Finally, the buyer enters sample information 68. In a 5 page into which the buyer enters sample information 120, 
preferred embodiment, sample information includes product information 122 and patient information 124. The 
volume, matrix, provider ID, sample ID, and medical field. buver ma y als0 enter aotes 126 M needed or appropriate. 
Different or additional sample information categories may, In a preferred embodiment, sample information includes 
of course, be used in accordance with the purpose and number of samples, price range, matrix and expiration date, 
function of the present invention. io Volume may also be included. Different or additional cat- 
Volume is preferably designated as a specified amount egorics of sample information may, of course, be used in 
and is given in units of either grams or milliliters. accordance with the present invention. 
Optionally, the buyer may specify volume as less than a Number of samples may be designated numerically as a 
specified amount, more than a specified amount, within a specified number, as less than a specified number, or as 
particular range, or as "low" or "high". 15 greater than a specified number. Number of samples may 

Matrix may include, among others, bulk sera, bulk also be entered more generally as "low" or "high", 

plasma, sera, plasma, cord blood, hair, saliva, semen, spinal Price ran ge may be designated numerically as a specified 

fluid, stool, tissue, urine, whole blood, anticoagulants, and number, or as less than a specified number, and should 

multiple matrix include a price base, e.g., per sample, per unit, etc. Price 

Provider ID typically designates the name of the provider. 20 2J*L may als ° be entered more generally 35 " low " or 

Sample ID refers to an identification number or code ' 

assigned to the sample during placement of the sample into Malrix specifies the form or substance of a sample. Matrix 

the inventory of the database 14. categories include whole blood, serum, urine, etc., and can 

Medical field includes a listing of available medical field 25 also s P ec * y whether the sample is contained in bulk sera or 

choices. A representative listing could include auto 15 P art °* a multiple matrix. A multiple matrix may be 

antibodies, cardiology, endocrinology, general chemistry, comprised of multiple samples from the same patient, such 

gynecology, hematology, infectious diseases, oncology, as a w , nole blood sam f 1 le and a unne sample Generally a 

pathologv, tropical diseases, dermatology, gastroenterology, multl P le matnx 15 a ^clion of samples that belong to the 

musculoskeletal, urology, neurology, pediatrics, same account, have the same lab idenUfication number and 

opthalmology, pharmacology, pulmonary and rheumatology, matrix - Sam P les may . also be m r to a co1 - 

and geriatric medicine. The medical field listing is displayed l f cll0a ^ own as a series. A series is a collection of samples 

by clicking on the down arrow adjacent the medical field lh / { !* lon S t0 the u same , account > have . the P atient 

data entry field identification number and the same matnx. 

Once entry has been made to all required fields, the buyer 35 Ex P iral ™ dale is lypically enlered by year ' fol,owed by 

submits the search query 70. In the preferred embodiment, month and day ' 

such submission is accomplished by clicking on the Volume may be designated numerically as a specified 

"Search" button on the "Samples" data entry page. The steps a mount, as less than a specified amount, as greater than a 

then proceed as already discussed in connection with FIG. 7 specified amount, or as within a specified range. Volume 

and are dependent upon whether or not a sample is found 40. 40 m ^ also be entered more generally as "low" or "high", and 

As already mentioned, if a sample is not found 40 and a ma y be m unils of milliliters or grams. Preferably the use of 

negative search result is returned, the buyer may post the g rams » limiled t0 tissue samples. 

desired item with special procurement 51 or may enter the In the preferred embodiment; "product" information may 

desired item into the wish list 52. &e designated according to three subcategories, namely 

Sample providers review wish list requests to see if any 45 product, diagnosis and drug, as has already been described, 

such requests match items in their inventory which are 0ther or additional categories may also be included as 

unlisted in the database or which are designated as private appropriate in accordance with the present invention, 

inventory. Upon finding a match, the sample provider may The buyer selects one of product, diagnosis or drug by 

enter the matching, but previously unlisted, sample into the clicking on the appropriate subcategory. An A-Z listing of 

database 14. The match is detected during a next routine 50 items within that subcategory is then displayed and a spe- 

review by the WIM host site for matches between inventory cific item may be selected. Clicking on the first letter of the 

and the wish list entries. Upon finding the match, the WIM desired item results in display of a list of items beginning 

host site generates an email to the requesting researcher wiln that letter. To select one of the items, the buyer clicks 

notifying the researcher that a sample meeting their listed on the item name which is then automatically entered into 

criteria is now available. 55 the "product" name field. 

Alternatively, when a buyer places an item on the wish In the preferred embodiment, patient information includes 

list, the WIM host site generates an email to subscribing age, gender and race. Other or additional categories relating 

sample providers identifying the wish information. One or t0 patient information may also be included as appropriate in 

more sample providers may respond with an offer to the accordance with the present invention, 

buyer of a specified, sample, which is conveyed through the 60 Age may be designated numerically as a specified 

host site. Should the buyer accept the offer, the WIM host number, as less than a specified number, as greater than a 

site notifies the sample provider of the acceptance. The specified number, or as within a specified range. Age may 

sample provider then adds the sample to its inventory, and also be entered more generally as "low" or "high". Gender 

the WIM host site generates an email to the buyer listing the and race have pull -down menus with available selections 

added samples. The buyer adds the samples to the shopping 65 listed. 

cart and the purchase sequence is initiated, as discussed in Once all required items have been entered, the buyer 

greater detail in connection with FIG. 11. submits the new wish 128 to the wish list. In the preferred 
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embodiment, such submission is accomplished by clicking 
on the "Add" button appearing on the "Add a New Wish" 
page. 

The buyer may choose to review his or her wish list by 
selecting "My Wishes" from the "Wish List" page. The 5 
wishes are listed individually and specify, for each wish, an 
identification number, the date the wish was entered, the 
specified matrix, product name, and whether or not there is 
a match in the database. A representative wish list is pro- 
vided in Table II. The researcher may review a particular 10 
wish in more detail by clicking on the appropriate identifi- 
cation number. The researcher may also delete a particular 
wish as appropriate, such as when a sample meeting the wish 
has been obtained. 

15 

TABLE II 



ID 


Date Matrix 


Product 


Match 


286 


14 Jan 00 Serum 


HSV 


No 


285 


14 Jan 00 Serum 


EBV 


No 


284 


12 Jan 00 Whole Blood 


Specific Proteins 


No 






Assayed at 3 








Different Levels 




277 


10 Jan 00 Whole Blood 


Lyphilized Drugs 


No 






Of Abuse Unassayed 








At Different Levels 




274 


10 Jan 00 Serum 


Rubella 


No 



20 



25 



30 



35 



The researcher may choose to search the Wish List. In a 
preferred embodiment, the researcher can search the Wish 
List for all wishes that have been posted for a specified 
number of days. For example, the researcher can specify a 
search of all wishes posted to the list within the last ten days. 
Alternatively, the researcher may search for wishes that have 
been on the Wish List for at least a specified number of days. 

In addition to the buyer's access to the wish list, sample 
providers may wish to search the Wish List. Referring now 
to FIG. 10, the sample provider may search the wish list by 
first clicking on the "Wish List" file tab to display the "Wish 
List Search" page 136. By entering data into the "Wish List 4Q 
Search" page, the sample provider may search for and 
display all wishes 138 posted within a specified number of 
days prior to the search. The default is 30 days, but alter- 
native periods may be selected by specifying a number of 
days 140. Alternatively, the sample provider may use the 4$ 
"Wish List Search" page to enter product information 142, 
patient information 144 and sample information 146, and 
initiate a search. 

In the preferred embodiment, "product" information may 
be designated according to three subcategories, namely 50 
product, diagnosis and drug, as has already been discussed. 
Other or additional categories may also be included as 
appropriate in accordance with the present invention. 

The sample provider selects one of product, diagnosis or 
drug by clicking on the appropriate subcategory. An A-Z 55 
listing of items is then displayed and a specific item may be 
selected. Clicking on the first letter of the desired item 
results in display of a list of items beginning with that letter. 
To select one of the listed items, the sample providerxlicks 
on the item name which is then automatically entered into 60 
the "product" name field. 

Product information further includes values, testing 
results and test manufacturer. Values represent a quantitative 
number for the product, diagnosis or drug, and may be 
entered as absolute values, such as 5, 10, 150, etc., or they 65 
may be entered as ranges of numbers, such as from 10 to 
100. Testing results may be selected as either a positive or 



a negative finding. Finally, results based on a specific type- 
of testing machine may be obtained by clicking on test 
manufacturer to display an A-Z listing of manufacturers. 
The manufacturer selected is automatically entered into the 
field. 

In the preferred embodiment, patient information includes 
age, gender, race, medical record available and doctor cer- 
tified. Other or additional categories may also be included as 
appropriate in accordance with the present invention. Entry 
into these fields has already been described herein, and may 
be referred to as also applicable here. 

In a preferred embodiment, sample information includes 
volume, matrix and notes. Different or additional sample 
information categories may, of course, be used in accor- 
dance with the present invention. 

Volume is preferably designated as a specified amount. 
The database is searched for samples on the wish list entered 
in both milliliters and grams. 

Clicking on "Matrix" reveals matrix categories that have 
been posted on the wish list. If the matrix being sought is not 
listed, then a sample with that matrix has not been posted on 
the wish list. If the matrix being sought is listed, then the 
appropriate selection is highlighted. 

The sample provider may also search for a sample on the 
wish list based on the notes entered by the potential buyer 
posting the wish list item. For example, to search for a 
sample on the wish list with notes that include the word 
"sera", the word "sera" is typed into the notes field. 
Similarly, if searching for "bulk sera" those words are typed 
into the notes field. The search will identify samples using 
the exact combination of words appearing in the notes field. 

Once all required field items have been entered, the 
sample provider submits the search query to initiate search 
148. In the preferred embodiment, such submission is 
accomplished by clicking on the "Search" button near the 
bottom of the "Wish List Search" page. 

If no match is found 150, the sample provider may choose 
to search again 151 using different criteria. If no additional 
searches are desired, the search ends 153. 

If a match to the search, query is found 150, the sample 
provider may choose to enter the matching sample 152 into 
the database 14. Once entered, the match will be detected by 
the WIM host site during a next routine review of inventory 
versus wish list entries. The WIM host site runs such reviews 
on a regular basis and preferably at least every 24 hours. 
Upon detecting the match, the WIM host site automatically 
generates an email message to the buyer who posted the 
matching wish list entry. The email message notifies the 
buyer that a sample meeting his or her wish list specifica- 
tions is available and prompts purchase 154. 

The steps to be undertaken when initiating a purchase 50 
are set forth in FIG. 11. Once a sample has been identified 
and found to be available, the buyer reviews and completes 
an order 76 for the sample. Orders are stored in the database 
in the orders and order 13 item tables. The ordering process 
may include selecting the desired samples and placing them 
into a temporary holding status, such as an electronic 
shopping cart, from which items may be deselected if 
desired. 

As noted earlier, the present invention may be configured 
to include advertising, most typically relating to the clinical 
research and medical fields. Display of some advertisements 
may be sensitive to the particular items being purchased, in 
a manner somewhat akin to the printing on grocery store 
receipts of coupons for the future purchase of particular 
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items responsive to the buyer's currently purchased items. 
Therefore, in response to the purchase of a particular matrix, 
for example, products supporting or otherwise relating to 
that matrix may be presented to the buyer for inclusion in the 
shopping cart. The buyer is, of course, free to ignore the 
prompts and can proceed with purchase of the desired 
samples. 

If the purchase represents the first time 78 the buyer has 
purchased, the buyer must choose a payment preference 80 
and be approved for purchase. 

If the buyer chooses to pay with a credit card 82, approval 
is typically obtained on-line 84 from an outside entity 
through the links for financial transactions 20. The outside 
entity sends an email 86 to the WIM host site confirming that 
approval has been granted or denied. Other means of obtain- 
ing approval may also be employed. 

If the buyer chooses to pay with a wire transfer 88, the 
buyer provides transfer instructions 90 on a wire transfer 
instruction page, including bank coordinates for the wire 
transfer. The wire transfer instruction page also includes a 
date box to be filled in with the date when the wire was sent, 
the bank name and the country name. An email to the WIM 
host site confirms 86 the transfer. 

If the buyer chooses to pay with a purchase order 92, the 
buyer chooses a category 94. In the preferred embodiment, 
the categories include Fortune 1000, universities and others, 
although other categories may also be specified in accor- 
dance with the present invention. The appropriate credit 
application is provided to the buyer responsive to the 
category selected; in the preferred embodiment, Fortune 
1000 companies receive immediate credit approval upon 
registration. 

Credit applications may be sent electronically or via 
facsimile, mailing, etc. The buyer completes the credit 
application 96, as applicable, and sends it to the WIM host 
site. At the WIM host site, received credit applications are 
placed in a credit application folder. In the preferred 
embodiment, this is a password protected folder maintained 
by the host site. Received credit applications are reviewed 
by personnel at the WIM host site. If the application is not 
approved 98, the WIM host site generates an email to the 
buyer declining 100 the buyer's request to purchase by 
purchase order. 

If the credit application is approved 98, the WIM host site 
generates an account number with a specified credit limit 
102 appropriate to the particular buyer. Account numbers 
and associated credit limits are placed in a credit accounts 
folder maintained at the WIM host site. The account number 
and credit limit of the approved buyer are then provided to 
a purchase authorization folder maintained at the WIM host 
site. 

In the preferred embodiment, the purchase authorization 
folder is a password protected folder. All emails confirming 
transaction approval, whether from credit card 82, wire 
transfer 88, or purchase order 92, are directed to the pur- 
chase authorization folder. Transaction approval is reviewed 
by personnel at the WIM host site for confirmation 104 of 
approval. 

If the transaction approval is confirmed, the buyer has 
been approved to make the requested purchase. During 
subsequent purchases, the buyer will be transferred directly 
to the purchase authorization folder for expedited transac- 
tion approval and is not required to repeat the initial credit 
authorization process for each purchase. 

Upon transaction approval, the WIM host site then gen- 
erates an email to the seller confirming transaction approval 
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106. The email may further include dollar amount, shipping 
address, handling fees, buyer shipping account numbers, etc. 

Upon receipt of the confirming email, the seller ships the 
order and confirms shipment 108. The confirmation of 

5 shipment is directed to an orders shipped folder at the WIM 
host site and includes a tracking number for the shipment. In 
the preferred embodiment, the buyer designates a form of 
shipment, and related shipping information. 

In response to shipment confirmation from the seller, the 

10 WIM host site generates emails to both the buyer and the 
seller 110. The email to the buyer includes an invoice with 
a description of the goods, total amount of the order, order 
number and shipment tracking number. The email to the 
seller is the same as the email to the buyer, but additionally 

15 includes a change of title credit slip for the specified invoice, 
less a transaction fee due to the WIM host site. A copy of 
each of the buyer and seller emails is retained in an invoice 
folder at the WIM host site. The invoice folder is preferably 
a password protected folder maintained by the host site. 

As noted earlier, the WIM system may also be used by 
sample providers as an inventory management service for 
private inventory. Sample providers can maintain private 
virtual "shelf space" on the host site which they can access 

25 from anywhere in the world using a web-enabled computer. 
Using techniques similar to those set forth in connection 
with buyer searching and sample provider searching of the 
wish list, sample providers can use the search engine of the 
WIM system to search within, review and update their own 

30 inventories, all at minimal cost to the sample providers. 
The foregoing descriptions and drawings should be con- 
sidered as illustrative only of the principles of the invention. 
The invention may be configured in a number of ways, using 
a variety of software and hardware, and is not limited by the 

35 configuration of the preferred embodiment. Numerous appli- 
cations of the present invention will readily occur to those 
skilled in the art. For example, the web-integrated inventory 
management system may be used to manage other types of 
inventory or as a clearinghouse for many kinds of specialty 

40 and non-specialty items. Therefore, it is not desired to limit 
the invention to the specific examples disclosed or the exact 
configuration and operation shown and described. Rather, all 
suitable modifications and equivalents may be resorted to, 
falling within the scope of the invention. 

45 What is claimed is: 

1. A method of implementing, with a central host site, an 
electronic commerce exchange for a web-integrated inven- 
tory of biological samples, the method comprising: 

inputting identification information on a plurality of bio- 
50 logical samples to a central host site inventory 
database, said plurality of biological samples belonging 
to at least one sample provider; 
inputting a search request to the database for a biological 
sample, the search request containing specified search 
55 criteria; 

searching the database for a biological sample matching 

the specified search criteria; 
displaying a search result; and 
60 notifying, in response to a positive search result, a poten- 
tial buyer of an availability of said biological sample. 

2. The method as set forth in claim 1, further comprising, 
in response to a negative search result, the step of: 

inputting a request for the biological sample to the central 
65 host site. 

3. The method as set forth in claim 1, wherein said 
identification information for each biological sample 
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includes data corresponding to specified fields, and said 
specified search criteria includes data corresponding to at 
least one of the specified fields such that the step of 
searching is conducted on a field by field basis. 

4. The method as set forth in claim 3, further comprising, 
in response to a negative search result, the step of: 

inputting a request for the biological sample to the central 
host site. 

. 5. The method as set forth in claim 4, the step of inputting 
a request including inputting the specified search criteria to 
a wish list of desired but currently unavailable biological 
samples, each desired biological sample on the wish list 
being described by data categorized in accordance with the 
specified fields. 

6. The method as set forth in claim 5, further comprising 
the steps of: 

accessing a search page within the central host site; 

entering, to the search page, data describing a non- 
■ inventory biological sample, the entered data catego- 
rized in accordance with the specified fields; 

searching the wish list of desired but currently unavailable 
biological samples in the database for a desired bio- 
logical sample described by data matching the entered 
data of the non-inventory biological sample; 

displaying a wish list search result. 

7. The method as set forth in claim 6, further comprising, 
responsive to a positive wish list search result showing a 
match between the desired biological sample and the non- 
inventory biological sample, the steps of: 

inputting identification information on the non-inventory 

biological sample to the central host site to add the 

biological sample to the inventory database as a newly 

available biological sample; 
comparing, by the central host site, the newly available 

biological sample to the wish list; 
identifying, by the central host site, a match between the 

newly available biological sample and the desired 

biological sample; and 
generating, by the central host site, an electronic message 

to a potential buyer notifying the potential buyer of the 

newly available biological sample. 

8. The method as set forth in claim 7, further comprising, 
responsive to the electronic message to the potential buyer 
notifying the potential buyer of the newly available biologi- 
cal sample, the steps of: 

requesting an availability of the newly available biologi- 
cal sample; 

generating, by the central host site, a first electronic 
message to a sample provider requesting confirmation 
of the availability of the newly available biological 
sample; 

receiving, by the central host site, confirmation of sample 
availability; 

generating, by the central host site, a second electronic 
message to the potential buyer confirming availability 
of the newly available biological sample; and 

initiating, through the central host site, purchase of the 
newly available biological sample. 

9. The method as set forth in claim 8, further comprising 
the steps of: 

receiving, by the central host site, a method of payment 
instruction; 

granting, by the central host site, transaction approval; 
generating, by the central host site, an electronic message 
to the sample provider confirming transaction approval; 
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shipping, responsive to transaction approval, the biologi- 
cal sample; 

receiving shipment confirmation at the central host site; 
generating, by the central host site, an electronic message 
5 with an invoice. 

10. The method as set forth in claim 5, further comprising 
the steps of: 

reviewing, by the central host site, newly available bio- 
logical samples added to inventory; 

10 comparing, by the central host site, the newly available 
biological samples to the wish list; 
identifying, by the central host site, a match between at 
least one of the newly available biological samples and 
the desired biological sample; and 

15 generating, by the central host site, an electronic message 
to a potential buyer notifying the potential buyer of the 
at least one newly available biological sample. 

11. The method as set forth in claim 1, further comprising, 
responsive to a positive search result showing a match 

20 between a biological sample and the specified search 
criteria, the steps of: 

generating, by the central host site, a first electronic 
message to a sample provider requesting confirmation 
25 of the availability of the biological sample; 

receiving, by the central host site, a response to the 

request for confirmation; 
generating, by the central host site, a second electronic 
message to a buyer with a status on availability of the 
30 biological sample. 

12. The method as set forth in claim 1, further comprising, 
responsive to a positive search result showing a match 
between a biological sample and the specified search 
criteria, the steps of: 

35 requesting an availability of the biological sample; 

generating, by the central host site, a first electronic 
message to a sample provider requesting confirmation 
of the availability of the biological sample; 
receiving, by the central host site, confirmation of.bio- 
40 logical sample availability; 

generating, by the central host site, a second electronic 
message to a buyer confirming availability of the 
biological sample; and 
initiating, through the central host site, purchase of the 
45 biological sample. 

13. The method as set forth in claim 12, further compris- 
ing the steps of: 

receiving, by the central host site, a method of payment 
instruction; 

50 granting, by the central host site, transaction approval; 
generating, by the central host site, an electronic message 
to the sample provider confirming transaction approval; 
shipping, responsive to transaction approval, the biologj- 
55 cal sample to the buyer; 

receiving shipment confirmation at the central host site; 
generating, by the central host site, an electronic message 
to the buyer with a first invoice and an electronic 
message to the sample provider with a second invoice. 
60 14. The method as set forth in claim 1, further comprising, 
in response to a negative search result, the steps of: 
inputting the specified search criteria to a wish list of 
desired but currently unavailable biological samples as 
a new wish; 

65 generating, by the central host site, an electronic message 
notifying subscribing sample providers of the new 
wish; 
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receiving, by the central host site, an offer from at least 

one subscribing sample provider of a biological sample 

responsive to the new wish; 
generating, by the central host site, an electronic message 

notifying the buyer of the biological sample being 

offered; 

generating, by the central host site, responsive to buyer 
acceptance of the offer, an electronic message notifying 
the sample provider of acceptance by the buyer; 

adding the biological sample to the central host site 
inventory database; 

generating, by the central host site, an electronic message 
to the buyer with the biological sample added; 

initiating, through the central host site, purchase of the 15 
biological sample. 

15. The method as set forth in claim 1, the step of 
inputting a search request including inputting a matrix and 
at least one sample parameter. 

16. The method as set forth in claim 1, wherein the 20 
specified search criteria may include in excess of ten sample 
parameters, each sample parameter describing a particular 
characteristic of the biological sample to which the search 
request is directed. 

17. A web-integrated inventory management system, 25 
comprising: 

a central host site having a database and a search engine 
for accessing the database, the database containing 
information identifying a plurality of biological 
samples according to a plurality of specified data fields, 30 mation 
said plurality of biological samples forming an inven 
tory; 



at least one sample provider registered with the central 
host site, said at least one sample provider owning 
biological samples listed within the inventory; 
at least one buyer, said buyer accessing the central host 
site using a computer and searching the database with 
the search engine for a desired biological sample, the 
buyer specifying the desired sample in accordance with 
specified search criteria that include data corresponding 
to at least one of the specified fields such that the search 
is conducted on a field by field basis; 

wherein, responsive to a positive search outcome, said 
central host site interfaces between an appropriate 
sample provider and said buyer to confirm sample 
availability and approve buyer credit, coordinating 
sample transfer from the appropriate sample provider to 
said buyer and effecting transfer of payment from said 
buyer to said appropriate sample provider. 

18. The system as set forth in claim 17, said central host 
site further comprising a wish list of desired but currently 
unavailable biological samples, additions to said wish list 
being input by buyers following a search of the database in 
which no match was found between a desired sample and 
biological samples within the inventory. 

19. The system as set forth in claim 17, wherein the 
specified fields include fields categorized as at least one of 
sample information, patient information and oncology infor- 
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( 57 ) ABSTRACT 
A blood component collection system with manipulation 
and optimization capabilities. In one embodiment process 
parameters are derived from an input/configured predeter- 
mined blood component yield and which is based upon the 
maximization of at least one process parameter. Thereafter 
the blood component collection procedure is performed with 
these derived process control parameters. In another 
embodiment, process parameters are derived from an input 
total procedure time from a maximized value for at least one 
of the other process control parameters so as to maximize 
blood component yield in this fixed time. Thereafter the 
blood component collection procedure is performed with 
these derived parameters. 



Patent Application Publication Oct. 25, 2001 Sheet 1 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 2 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 4 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 5 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 6 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 7 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 8 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 9 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 10 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 11 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 12 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 13 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 14 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 15 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 16 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 17 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 18 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 19 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 20 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 21 of 44 US 2001/0034614 Al 




5^ 



Patent Application Publication Oct. 25, 2001 Sheet 22 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 24 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 25 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 26 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 27 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 28 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 29 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 30 of 44 US 2001/0034614 Al 





\ 



Patent Application Publication Oct. 25, 2001 Sheet 34 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 35 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 36 of 44 US 2001/0034614 Al 



s 



I .1 



«* § £ ^ 



i 



II 




_§ *X X 

8833 



» i 
1 1 









If 


1 

C7 


riii 



E 

o 

S3 ^ 





5 



Patent Application Publication Oct 25, 2001 Sheet 37 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 38 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 



Sheet 39 of 44 US 2001/0034614 Al 




Patent Application Publication Oct. 25, 2001 Sheet 40 of 44 US 2001/0034614 Al 



CO 
CO 




Patent Application Publication Oct. 25, 2001 Sheet 41 of 44 US 2001/0034614 Al 



INPUT/CONFIRM DONOR DATA 
(CENTRAL STATION 148) 



INPUT/CONFIRM COLLECTION 
PROCEDURE (CENTRAL STATION 148) 



I 



GENERATE INITIAL PROCEDURE ORDER (CENTRAL 
STATION 148 OR SYSTEM INTERFACE MODULE) 



T 



TRANSFER/DOWNLOAD COLLECTION DEVICE 
CONTROLLER (e.g. MEMORY MEDIUM 142) 



NO 



T 



YES 



OPTIMIZATION OPTIONS 
(i.e. MEDIUM 142) 



I 



YES 



PRODUCT-BASED: 
SINGLE PLATELET 
PRODUCT 



YES 



PRODUCT-BASED: 
DOUBLE PLATELET 
PRODUCT 



TIME-BASED 



GENERATE MODIFIED 
PROCEDURE ORDER 



LOAD PROCEDURE 
ORDER 



PERFORM COLLECTION 
PROCEDURE (E.G. DEVICE 18) 



DATA TRANSFER BACK TO CENTRAL 
STATION (e.g. MEMORY SYTEM 142) 



Figure 9 A 



Patent Application Publication Oct. 25, 2001 Sheet 42 of, 44 US 2001/0034614 Al 




Patent Application Publication Oct 25, 2001 Sheet 43 of 44 US 2001/0034614 Al 



START 



172 



SPECIFY 184 
PARAMETERS \S 
(R.l.YORtp) 




ASSUMED 



YES 



196* 



ADJUST 
tp-c 



NO 



188 



DERIVATIONS 



z 



(Q 



IN-C 



OR 



— r 



CALCULATE Q u 
FOR E 0PT 



192 




YES 



0| N -C<Ql 



NO 



EXIT 

OPTIMIZATION 
COMPLETE 



176 



Q|N-C=°L 



YES 



Figure 9C 



Patent Application Publication Oct. 25, 2001 Sheet 44 of 44 US 2001/0034614 Al 



US 2001/0034614 Al 



1 



Oct. 25, 2001 



EXTRACORPOREAL BLOOD PROCESSING 
INFORMATION MANAGEMENT SYSTEM 

[0001] This case claims the benefit of priority of U.S. 
provisional patent application serial No. 60/186,123, filed on 
Mar. 1, 2000. 

FIELD OF THE INVENTION 

[0002] The present invention generally relates to the field 
of extracorporeal blood processing systems and, more par- 
ticularly, to providing information management and/or data 
manipulation and/or optimization capabilities to, in and/or 
with such systems. 

BACKGROUND OF THE INVENTION 

[0003] The utilization of blood taken from donors and 
transfused into recipients is well known for purposes of 
treating medical conditions. More recently, selected blood 
components have been separated and collected from donated 
blood for subsequent transfusion into recipients for the more 
specific therapeutic benefits of those particular blood com- 
ponents. The primary blood components of current interest 
in many separation and collection technologies include 
platelets, red blood cells, white blood cells, stem cells and 
plasma. 

[0004] In the harvesting of blood components, blood is 
removed from a donor through a needle assembly or other 
blood access device and may thereafter be processed by 
centrifugation or other appropriate separation techniques to 
isolate and collect the desired components. This procedure is 
often carried out very effectively in an on-line procedure 
wherein blood is removed from a donor, processed in and 
through a disposable extracorporeal fluid circuit to obtain 
the desired components, and the uncollected components 
thereafter returned to the donor. Two illustrative blood 
component collection systems which provide for this type of 
on-line blood component collection procedure are the 
COBE® Spectram™ and Trima® apheresis systems which 
are commercially available from the assignee of the present 
application. 

[0005] The yield of a particular collection of blood com- 
ponents from such a process is an important factor in the 
ultimate usefulness of those particular components. For 
instance, in the United States a minimum yield is associated 
with a collected blood component product in order for that 
product to meet certain criteria and qualify for use as a 
transfusable blood component product. The COBE® Spec- 
tra™ and Trima® apheresis systems presently accommodate 
for this requirement by processing certain donor biological 
data such as height, weight, gender, and platelet pre-count or 
hematocrit, together with pre-configured and/or operator- 
input data such as the total procedure time, and system- 
related data such as the type of collection procedure (e.g., 
single or double needle) and collection efficiency to generate 
certain process parameters such as the inlet flow to the 
apheresis centrifugation device (including, for example, the 
combined flow of whole blood from the donor plus typically 
a flow of anticoagulant). These apheresis machines then 
generate a predicted blood component yield from these data 
as well. 

[0006] An additional consideration presently in the United 
States, for example, relating to blood component yield is that 
the yield is determinative of the product classification. With 
regard to platelets, a single platelet product is presently 
considered to be a collection of 3x1 0 1 3 platelets and a double 



platelet product is considered to be a collection of 6x10" 
platelets. If a collection is between 3x10" and 6x10 11 
platelets, it is still considered to be a single platelet product. 
This classification as a single or double platelet product is 
important to blood component collection facilities (e.g., 
blood banks/centers) since a double platelet product may 
have a higher selling price than a single platelet product and 
may also have a greater benefit for the recipient/ patient. The 
yield of a particular collection of blood components may 
also be a relevant consideration for certain therapeutic 
treatments (e.g., red blood cell or plasma exchanges). 

[0007] Furthermore, advances in blood component collec- 
tion technologies offer the possibility of collecting multiple 
combinations of products from a single donor. These prod- 
ucts can be defined within a large range of volumes and 
contents. Add to this multitude of collection choices, a 
multitude of donors with differing physiologies, each being 
subject to potential variations in collection procedures to 
yield a potential very large plurality of choices of products 
to be collected, as may be desired. 

[0008] Still other important considerations relating to 
blood component collection systems relate to the donor and 
product demand. For instance, blood component collection 
facilities are not only experiencing an increase in the overall 
demand for blood components, but the demand now typi- 
cally varies between the blood component types as well. 
Moreover, the supply of donors is unfortunately inadequate 
in many cases, and donor time constraints are becoming 
more prevalent. Furthermore, obtainable yields from a given 
donor may vary from one blood component to another, i.e., 
one donor may be a better platelet source than a red blood 
cell source. 

[0009] The result is a large number of variables which 
must preferably be simultaneously managed in order to meet 
the blood bank collection goals which will thus also satisfy 
the needs of the ultimate hospital or like customer. Com- 
puterized information systems are tools which are beginning 
to prove useful in assisting in controlling parts of blood 
collection processes. This will likely further impact, if not 
transform, how blood banking will be managed in the future. 
Computer information systems may prove important in 
aiding the provision of just-in-time supply of products to 
meet customized demand for blood products and better 
satisfying the individual needs of patients and providers. 
Automated component collection systems will also allow for 
flexibility in producing customized blood products in a 
just-in-time fashion from potentially fewer donors to help 
meet the demands of patients and providers. 

[0010] In view of the foregoing, it should be readily 
understood that better management of the various aspects of 
blood component collection processes and systems is 
increasingly desirable in providing preferred product col- 
lection and customer supply options. 

SUMMARY OF THE INVENTION 

[0011] The present invention relates in one application to 
a blood component collection system and the provision of 
management capabilities which may include the incorpora- 
tion of data manipulation and/or optimization principles. 
Generally, the present invention preferably utilizes an infor- 
mation management system which provides simplified 
donor data storage and control as well as communications 
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with actual blood component collection machines to both 
ease and optimize the set-up and operation thereof. The 
principles of data manipulation and/or optimization are 
further improved also, particularly in terms of the individual 
donor, a given pool of donors, the particular blood compo- 
nent collection system, and/or the blood component product 
or products to be collected. For instance, the present inven- 
tion may be adapted to provide for the collection of a 
predetermined quantity of at least one predetermined blood 
component, or more typically the collection of such blood 
components within a particular range in a "minimum" 
amount of time, and/or for the collection of a "maximum" 
quantity of at least one predetermined blood component in 
a fixed amount of time, all based upon certain donor and/or 
blood center defined process conditions. Moreover, the 
present invention may be adapted to provide for blood 
component inventory control by basing donor selection 
and/or collection procedure selection (in terms of the type of 
blood component to be collected) on blood component 
demand and/or existing inventory. In addition, the present 
invention may be adapted to provide for further donor 
management by collecting that blood component type or 
types from the donor which provides a maximum yield. 

[0012] A preferred central computational, data storage, 
manipulation and communication system serving as the 
primary basis of the present invention is preferably a soft- 
ware-type of application run in tandem with one or more 
hardware devices including, for example, a data input 
device, a data storage device, a data manipulation device and 
one or more communications devices which connect in data 
communication relationship one or more of such input, 
storage and/or manipulation devices to at least one blood 
component separation and/or collection machine. The soft- 
ware application may be and in preferred form is operable 
in/on a Microsoft® Windows® software platform (or a 
similar such system) that allows blood donation center 
operators to prepare apheresis machines and donors for 
apheresis donations in an automated manner. The present 
system may preferably have two primary components, a 
computation/manipulation application with associated soft- 
ware and devices, and a server system also including asso- 
ciated software and devices. The computation/ manipulation 
application is used by the blood center staff to perform data 
management and/or manipulation functions. The server sys- 
tem is used preferably to store data and provide communi- 
cations with the apheresis machines and/or other informa- 
tion systems. In a typical setting, one or more operators from 
different locations within a single blood center and/or 
remotely from various disparate blood centers (and/or other 
sites) can communicate with a centralized server system to 
perform specific functions such as donor check-in, preparing 
a donor for a particular donation, or finalizing and/or pre- 
paring reports on collection activities, inter alia. 

[0013] An important purpose of the present system is to 
address various challenges in the area of blood donation 
management including increasing productivity, better donor 
qualification/utilization and improved product quality con- 
trol and disposition. 

[0014] Increased productivity may be accomplished 
through centralized management of apheresis machine con- 
figurations. Operators and/or system administrators may 
easily create and store several configurations using the 
present system on a centralized server/computer or a like 



environment. These configurations are preferably kept in a 
centralized database and can be downloaded to each apher- 
esis machine on a permanent or a temporary/one-time dona- 
tion basis. This reduces the inherent contemporary difficulty 
of editing apheresis machine configurations by allowing the 
operator to update a centralized configuration and not be 
required to repeatedly make the same change on several 
standalone apheresis machines. 

[0015] Donor quah'fication/utilization may be improved 
through procedure customization and/or optimization. Each 
donation may be customized by this system to account for 
the current needs of a blood center and/or optimized by what 
each particular donor is eligible/qualified for or capable of 
donating. This allows the operator to determine what prod- 
uct or combination of products will best be collected even 
before the donor is connected to the machine. It also allows 
the blood center operators to see what tubing set is required 
for the donation. With this information the customer can 
avoid wasting tubing sets and reduce incomplete procedures. 
Decision support for donor eligibility is a preferred benefi- 
cial feature of the system. At a minimum, eligibility may be 
determined by the interval between donations, the number of 
donations previously given, the blood component loss over 
a period of time, and other donor screening issues. 

[0016] Another important, yet optional feature of donor 
qualification/utilization and management in using a system 
of the present invention involves donor recruitment. The 
present invention provides a tool which may analyze and 
predict donation outcomes prior to running a donor on an 
apheresis machine. Such a tool can use donor and procedure 
information from the central database or optionally from an 
imported text file containing the required minimum infor- 
mation. Thus, such predictions can be used independently of 
actual runs on donors, even those actual runs involving the 
system of the present invention. These predictions may also 
be independent of procedures not currently entered into the 
central database, but rather from data generated by the blood 
center or data obtained from the blood center information 
system. Donor data may refer to a particular donor or to a 
statistical distribution of donor population. At a minimum, 
the system of the present invention may preferably analyze 
the outcomes of the following three scenarios: a) a single 
donor relative to many possible procedures; b) many donors 
relative to a single type of procedure; and c) many donors 
relative to many possible procedures. 

[0017] Improved product disposition may be enhanced 
through the provision of alterable prioritizations of the 
product needs of a blood center. The present system presents 
the capability of providing a prioritization of which products 
are preferred to be collected. This allows the blood center to 
begin to incorporate the concept of demand drive where 
donors are used to fill existing and/or imminent product 
needs. This also reduces waste from the over collection of 
certain products. The system also presents the capability to 
tailor a blood center's priorities by blood type, CMV status, 
and/or HLA type matching. 

[0018] The present system also provides for quality con- 
trol (QC) in the entry of laboratory data for products 
collected by blood separation devices operated in accor- 
dance with the present invention. Data may include (but is 
not limited to) measured yields, volumes, concentrations, 
product contaminants, and pH levels. The present system 
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provides the capability to associate anomalous QC lab data 
to donation events and to generate exception reports where 
the device prediction and QC lab results may differ. The 
present system can also utilize this data to automatically 
calculate and adjust a separation device's yield calibration 
value, i.e., a yield scaling factor, depending on the particular 
device type. 

[0019] Overall procedure and apheresis machine manage- 
ment may also be improved by recording procedure history 
information for each apheresis donation and storing it in a 
central database. Thus, the system may contain a detailed log 
of each donation. These logs can include procedure com- 
ments, tubing sets used, alarms experienced, adjustments 
made, and machine run summary information. Operators 
may additionally annotate this procedure history informa- 
tion and/or obtain reports using such logged information. 

[0020] To implement the above and other features of the 
present invention, it is preferred that a central computa- 
tional/data storage system be established according to the 
present invention so that it communicates with each of one 
or more blood collection machines, preferably apheresis 
machines, in both directions (even though one-way commu- 
nications may be desirable in certain situations). Two way 
communications provide for directing to each machine con- 
figuration information of both temporary and permanent 
natures, procedural lists and priority information, donor vital 
information, including height, weight, gender, blood com- 
ponent pre-counts and total blood volume (TBV), as well as 
donor identification which may include a donor picture with 
the donor's name and perhaps the date of birth. The cen- 
tralized system may then also communicate in the reverse 
direction with each machine to retrieve from each apheresis 
machine immediate information regarding conditions such 
as alarms, procedure adjustments, and run progress (product 
collection information) for monitoring purposes. It also 
provides for retrieving end of run summary information and 
run logs after each procedure is complete. The centralized 
system can also use data from the apheresis devices to detect 
and isolate potential maintenance problems before they 
manifest themselves to the blood center. These can then be 
reported so that preventive maintenance may be performed. 

[0021] The present system preferably uses prediction 
algorithms like those used in the Trima® and/or Spectra™ 
apheresis machines. Moreover, the prediction algorithms 
can also be applied to individual donors, a reference donor 
list, and/or ranges of donors within the database. This 
capability is helpful to predetermine donor eligibility for 
specific product collections, and what products would be 
available given specific apheresis machine configuration 
settings. 

[0022] The present system has been developed with an 
open architecture to provide integration capabilities and 
collaborative capabilities with other computing environ- 
ments (such as Mak and/or Wyndgate donor database infor- 
mation systems) and/or with other component separation 
machines (such as the Haemonetics and/or the Baxter series, 
e.g., the MCS+ and/or the Amicus and/or CS-3000 apheresis 
machines, inter alia). This ultimately will allow ancillary 
applications to be used. For example, this allows for the 
manipulation and formatting of donor identification data 
and/or images obtained from other information or software 
systems. Bar code capability is another preferable alterna- 



tive which may be incorporated into the present system. Any 
field entry point which could/would require keyboard data 
entry could be filled using a bar code reader. In addition, 
special entry fields such as unit or batch number, manufac- 
turer and expiry dates of disposable tubing sets may be fully 
decoded utilizing administratively editable decoding infor- 
mation; an example is manufacturer identification of a 
disposable tubing set. 

[0023] Products can also be customizable from a collec- 
tion standpoint. This is a potential first step toward a 
"dosing" mode] whereby components may be collected in 
quantities matching specific medically or doctor prescribed 
doses. These customizable products, although perhaps not 
directly donor specific, could also be set up in a way to take 
care of situations such as a "first time" donor or persons 
known as "dumpers," i.e., those persons whose component 
products show a certain tendency to clump or aggregate. 

[0024] After determining which product or products are to 
be collected, each donor can be assigned to a specific 
apheresis machine. Monitoring real-time machine status 
from a central system is useful to determine to which 
machine each donor should be sent. 

[0025] The present system has been designed to satisfy an 
optional yet desirable three room operational flow scenario. 
The basic three room scenario involves processing donors 
sequentially through three steps which may correspond to 
three different rooms; namely, donor registration or recep- 
tion, donor interview/screening and donor utilization rooms. 
This model has been suggested for providing smooth opera- 
tion of the blood component collection process. 

[0026] During or after the run, numerous standard reports 
may be made available to provide the donation center 
information related to specific runs, sequences of runs, 
exceptions, etc. Although the reports are preferably stan- 
dardized, customization may also preferably be made pos- 
sible through the simple use of report wizards. The present 
system preferably also utilizes an industry standard report 
engine. 

[0027] The central database provides the system with the 
capability of storing and maintaining data relevant to the 
entire blood component collection process such as, donor 
demographic information, machine configuration informa- 
tion, run information and lab result information. Lab data 
can also be entered into the run record to complete the 
product collection run record. This data can be used to 
provide feedback to the process. The communication soft- 
ware and hardware enable the pulling of data from and 
transmission of data to a common or central data repository. 

[0028] This system may be used in a stand-alone configu- 
ration or in collaboration with a blood banking information 
system, especially for transfer of donor demographics and 
like donor identification information. The blood center infor- 
mation system is preferably considered the master when 
linked. Fire wall protection may be provided through pass- 
word protection schemes, message formatting requirements 
and/or hardware communications interfaces. This provides 
the assurance that the integrity of the apheresis machine is 
maintained during connectivity of this system with such 
machines(s) and/or with other systems. The present system 
can also utilize a "standard" customer network for commu- 
nications between a central system server and operators. 
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This concept of collaborative networking particularly with 
pre-existing networks can minimize the "re-wiring" that 
otherwise might have been necessary. 

[0029] Connectivity may also be utilized to provide col- 
lection data to the blood bank information system after the 
run is complete. This two-way communication strategy 
allows the present system to optimize the procedure and 
device selection based on the blood center's current priori- 
ties, rather than making these selections less-optimally at 
donor registration time. The as-run collection data may also 
synchronize the blood bank information system to the actual 
products, yields, and volumes donated. 

[0030] Further, this system preferably utilizes formal and 
de-facto standards such as SQL interfaces to the database, 
ethernet protocols for communications, and preferably 
Oracle® reports for report generation. 

[0031] In the present system, an apheresis machine, which 
is preferably also operable in an off-line mode, may upload 
run information to a central server system when the apher- 
esis machine is connected on-line with the central server 
system. This feature could also be used for mobile or 
satellite operations. 

[0032] An additional preferred functionality is connectiv- 
ity with a blood center information system. Donor data will 
preferably be down-loadable to the central server system of 
the present invention from the blood center information 
system. This will allow real time updating of donor data in 
the central database of the present invention from the 
database of the blood center information system. Other 
alternatives of the present system may also include connec- 
tivity of the central data manipulation and/or storage system 
to apheresis machines from a plurality of manufacturers. 

[0033] Of the various methods of data transfer available, 
an option is a web server set-up. With specially developed 
applets, this allows the local user or a remote user (with 
permission) to browse the operator s database for pertinent 
information. Thus, this system can also be accessed 
remotely and provides an external "gateway" to run-logs 
from each apheresis machine. Security can be established to 
obscure sensitive data. An administration/security optional 
feature would allow the system to be configured with the 
concept of user types for security. A system administrator 
would have the most privileges and a guest would have the 
least number of privileges. 

[0034] The present system provides an opportunity to 
circumvent shortcomings in the operational procedures 
forced on a blood center by the use of pre-existing blood 
bank software. Specifically, the present system may over- 
come the problem of a blood bank software system pre- 
selecting blood components to be collected rather than 
having the present system perform this selection process. 
The way this is achieved is unique in that data is exchanged 
with the blood bank software system during the process flow 
of information. This is different from having either system 
depend on inputs from the other system and then wait for 
outputs. 

[0035] The present invention also preferably may be char- 
acterized as a blood component collection system having 
blood component product-based or time-based optimization 
capabilities. One embodiment comprises a method for col- 
lecting at least one predetermined blood component (e.g., a 



collection of platelets or red blood cells or plasma) from a 
source of whole blood using a blood component collection 
system which includes a blood component collection device 
running according to a particular collection procedure. More 
particularly, a desired yield of the predetermined blood 
components) may be identified (such yield including a 
single yield or range of yields) and biological data relating 
to the source of whole blood is provided to the blood 
component collection system. This data may also include 
statistically developed modifications based upon categories 
of data for multiple sources of whole blood as contained 
within the central server systems. Also, a value or magnitude 
may be associated with each of the various process param- 
eters used in the collection procedure. A magnitude of at 
least one of these process parameters is preferably derived 
from the biological data and the desired yield and optionally 
also the statistically derived data from a plurality of whole 
blood sources. These magnitudes, including all magnitudes 
of process parameters derived from the desired yield, are 
input to the blood component collection system. Thereafter, 
the collection procedure is performed with the blood com- 
ponent collection device and with the input process param- 
eters to collect the desired yield of at least one predeter- 
mined blood components) from the whole blood source. 

[0036] In a time -based optimization method, a total pro- 
cedure time for the collection procedure is identified (e.g., 
based primarily upon donor time availability). One potential 
inlet flow to the system is derived from at least this identified 
total procedure time. Another potential inlet flow to the 
system is derived which provides an "optimum" collection 
efficiency and is effectively the apex of a bell-shaped yield/ 
inlet flow curve (i.e., the inlet flow which provides the 
maximum blood component yield). Consequently, if the 
total procedure time-based inlet flow is greater than the 
maximum yield-based inlet flow, and thus is an inlet flow on 
the decreasing slope portion of the yield/inlet flow curve, the 
maximum yield-based inlet flow magnitude is used in the 
performance of the collection procedure. However, if the 
total procedure time-based inlet flow is less than the maxi- 
mum yield-based inlet flow, and thus is an inlet flow on the 
increasing slope portion of the yield/inlet flow curve, the 
total procedure time-based inlet flow magnitude is used in 
the performance of the collection procedure. 

[0037] The subject invention provides greater efficiency in 
blood component collection and management. For example, 
the present invention can be used to compare blood bank/ 
center component inventories with projected needs, and 
adjust collection procedures to meet these needs. Further, the 
present invention provides benefits to donors. In particular, 
certain information relating to the donor's physical and 
medical characteristics may be stored in the system and 
utilized during subsequent visits by the donor to derive 
magnitudes for the various process control parameters. For 
example, for a donor with an anticoagulant intolerance, the 
magnitude of the anticoagulant infusion rate may be set so 
as to not exceed the donor's tolerance. 

[0038] The present invention may be implemented as a 
computer process, a computing system or as an article of 
manufacture such as a computer program product. The 
computer program product may include a computer storage 
medium communicatively connected to and/or readable by a 
computer system and may include encoding of a computer 
program of instructions for executing a computer process. 
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Such a computer program product may also be a propagated 
signal on a carrier readable by a computing system and may 
also include encoding of a computer program of instructions 
for executing a computer process. 

[0039] These and other features of the present invention 
can be better understood from the following detailed 
description of a preferred embodiment of the present inven- 
tion taken in conjunction with the accompanying drawings 
which are briefly described below. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0040] FIG. 1A is a schematic representation of a blood 
processing information management system in accordance 
with principles of the present invention; 

[0041] FIG. IB is another schematic representation of a 
blood processing information management system in accor- 
dance with principles of the present invention; 

[0042] FIG. 1C is yet another schematic representation of 
a blood processing information management system in 
accordance with principles of the present invention; 

[0043] FIG. ID is still another schematic representation of 
a blood processing information management system in 
accordance with principles of the present invention; 

[0044] FIGS. 2A-21 are display screen depictions of data 
entry, retrieval and/or manipulation display pages for use in 
accordance with the present invention; 

[0045] FIGS. 3A-3F are further display screen depictions 
of data entry, retrieval and/or manipulation display pages for 
use in accordance with the present invention; 

[0046] FIGS. 4A and 4B are still further display screen 
depictions of data entry, retrieval and/or manipulation dis- 
play pages for use in accordance with the present invention; 

[0047] FIGS. 5A and 5B are yet still further display 
screen depictions of data entry, retrieval and/or manipulation 
display pages for use in accordance with the present inven- 
tion; 

[0048] FIGS. 6A through 6M are another set of display 
screen depictions of data entry, retrieval and/or manipulation 
display pages for use in accordance with the present inven- 
tion; 

[0049] FIG. 7A is a schematic representation of one 
embodiment of a blood component separation assembly 
which utilizes a dual needle configuration and which may be 
incorporated into the blood component collection systems of 
FIGS. 1A-1D; 

[0050] FIG. 7B is a schematic representation of one 
embodiment of a blood component separation assembly 
which utilizes a single needle configuration and which may 
be incorporated into the blood component collection systems 
of FIGS. 1A-1D; 

[0051] FIGS. 8A and 8B are isometric and top views, 
respectively, of one type of a disposable blood processing 
channel which may be used in the blood component collec- 
tion device of FIGS. 7A and 7B; 

[0052] FIG. 9A is a flow chart of a blood component 
collection procedure utilizing principles of the present 
invention; 



[0053] FIG. 9B is a flow chart of one optimization model 
for deriving at least one optimal process parameter from a 
desired blood component yield or from a total procedure 
time in accordance with principles of the present invention; 

[0054] FIG. 9C is a flow chart of one optimization model 
for deriving at least one optimal process parameter from a 
desired blood component yield or from a total procedure 
time in accordance with principles of the present invention; 
and 

[0055] FIG. 10 is a yield/inlet flow curve. 

DETAILED DESCRIPTION 

[0056] The present invention will be described with ref- 
erence to the accompanying drawings which assist in illus- 
trating various pertinent features hereof. One application of 
the present invention involves one or more blood component 
collection systems which separate, remove, and collect at 
least one type of blood component (e.g., platelets, red blood 
cells, stem cells, white blood cells, plasma) from a source of 
whole blood (e.g., a donor) through utilization of a collec- 
tion procedure derived from a typically site-configured 
and/or operator-input goal or set of goals and may optionally 
also include a "maximization'* of at least one process control 
parameter. This type of maximized parameter derivation is 
referred to herein as an "optimization process" and the 
derived process control parameters may be referred to herein 
as "optimal values." 

[0057] Referring to the schematic of FIG. 1A, a first 
alternative schematic representation of the present invention 
is shown as including a blood component collection and 
information management system generally identified by the 
reference numeral 2. The system 2 would typically be 
implemented at a blood bank/center (not shown in FIG. 1A). 
The system 2 may include a substantially centralized com- 
puting/data storage assembly 140 (e.g., including an appro- 
priate microcomputer and/or microprocessors) such as a 
Windows®-based standard desktop or laptop computer (or 
other like platform(s)), including therein or communicating 
with at least one memory device with corresponding appro- 
priate software, etc. (not shown separately in FIG. 1A)) and 
at least one blood component separation/collection assembly 
(three shown), each generally identified with respective 
reference numerals 10 (in FIGS. 1A-1D). Each such sepa- 
ration collection assembly 10 preferably includes a blood 
component separation and collection device 18 as an integral 
part thereof. As will be discussed below, the centralized 
computing/data storage assembly 140 (or at least a portion 
thereof) and the associated blood component collection 
assemblies 10 are preferably appropriately interfaced with 
each other in electronic or electromagnetic data communi- 
cation relationship as will be described, but may also and/or 
alternatively be disposed in a physically separate disposition 
from each other particularly during non<ommunication 
operation. That is, component separation/collection, data 
communication, retrieval, manipulation, and optimization 
procedures in accordance with principles of the present 
invention are not limited to being performed at any particu- 
lar physical location of apheresis machines(s) 10 relative to 
a central assembly 140. Furthermore, data entry, manipula- 
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tion and storage may still be performed at/on each machine 
10 using, for example, respective interfaces, which here are 
shown as preferred touchscreen input/output devices 199. 
[0058] A further aspect of the present invention is shown 
in more detail in FIG. IB wherein a centralized computing/ 
data storage assembly 140 is shown schematically disposed 
in communicative relationship with various types of blood 
component collection machine assemblies 10 as well as to 
either a discrete blood center information system within a 
blood center 1000 or a hospital information system within a 
hospital 1001, or both. Thus, as will be described in further 
detail below, a centralized computing/data storage assembly 
140 may preferably make broad use of multiple communi- 
cation connections (including satellite and/or wide area 
networks (WAN's), for example). Note also that though 
preferable connections to Trima® apheresis machines 10 
(available from the assignee of the present invention) are 
shown and described throughout; these are intended as 
exemplars only. As shown in FIG. IB, connections can be 
made to numerous other machines as well, such as COBE® 
Spectra™ apheresis machines and/or Baxter, Inc. and Hae- 
monetics Corporation apheresis machines (such as the 
CS-3000, the Amicus and the MCS+ apheresis machines, 
inter alia). The currently preferred machines 10 are, as 
shown, Trim a® apheresis machines 10 (see e.g. FIGS. 
1A-1D). However, a representation of a COBE® Spectra™ 
machine is also shown in FIG. IB, identified therein gen- 
erally by the reference numeral 10A, and a Baxter Amicus 
machine and a Haemonetics MCS+ machine are also shown 
in FIG. IB and identified by the respective reference numer- 
als 10B and IOC. Use with a more traditional manual whole 
blood collection system is also shown schematically in FIG. 
IB, generally identified by the reference numeral 10D, 
therein. Thus, this system is intended to and will operate 
with various apheresis as well as whole blood collection 
systems. 

[0059] Generally, a centralized computing/data storage 
assembly 140 may include, as shown schematically in FIG. 
1A, a central station 148 which may include, for example, 
data input/entry devices generally identified by the reference 
numeral 149. Such devices 149 may, more particularly, 
include a keyboard 149A, a mouse 149B, and/or if desired, 
devices such as a barcode reader (not shown), and/or a 
digital camera (not shown) and/or an input/output display 
monitor and screen 200 as these may be known in the art. 
Various internal hardware and software elements, again as 
known in the art are also intended to be included within a 
central station 148. Further, the centralized computing/data 
storage assembly 148 may include a data manipulation 
device 144 (disposed within station 148 in FIG. 1A) which 
is preferably closely associated with and in some embodi- 
ments is perhaps inseparable from the central station 148. 
Manipulation device 144 may be an appropriate processor as 
used in a computer system such as may be used in a 
microcomputer or otherwise standard desktop or laptop 
personal computer (PC) including a preferably Windows®- 
based operating system and may further include other 
devices and attendant manipulation software (whether resi- 
dent on/in the processor or resident in other associated 
memory devices but closely associated with the processor). 
A further preferred element of the computing/data storage 
assembly 140 is the storage medium 142 (not separately 
shown from central station 148 in FIG. 1A) used for data 
storage. The storage medium 142 may also be closely 



associated with the other elements of the assembly 140, i.e., 
the central station 148 and the manipulation device 144, or 
as with those other devices it may be dissociated in physical 
space but communicatively associated therewith through 
space (via cabling or energy wave communications, inter 
afia), so long as these elements cooperatively interact func- 
tionally. Hardware and software which may make possible 
data communication between various elements of assembly 
140, as well as between assembly 140 and myriad possible 
external devices, some of which are like those shown in 
FIGS. 1A and IB, are hereafter referred to as a communi- 
cation or server subsystem 146. Subsystem 146 may also be 
mainly disposed on or in the assembly 140 and/or may be 
mostly physically disparate therefrom so long as it provides 
the data communication functions described herein. 
[0060] Thus, the assembly 140 may be referred to as a 
whole for performance of the inputting and maintaining of 
donor-related data functions (principally through use of the 
central station 148, communication subsystem 146, and the 
storage medium 142), and also typically for the preparation 
of an initial procedure order (the process control parameters 
derived from the donor-related data and other consider- 
ations) for a given donor (through use primarily of the data 
manipulation device 144 together with the data obtained 
from either or both of the other elements 148, 142 as 
communicated by and through the subsystem 146). 
[0061] Though perhaps not preferred, there may remain 
various situations in which it may be desirable to maintain 
the ability to perform data entry and/or manipulation pro- 
cedures/ functions at the corresponding pre-existing opera- 
tor interface 199 of each particular apheresis machine 
assembly 10 as well. In such situations, a central computing/ 
database assembly 140 may thus not be required for opera- 
tion of assembly 10 even if still provided. Note in the 
preferred apheresis machines 10 shown in FIG. 1A (such as 
the Trima® machines 10 described above), the computing/ 
database and data entry and manipulation capabilities are 
available in and would thus be able to continue to separately 
provide these functions, if desired. Moreover, this could still 
occur even when connected through a central communica- 
tions system 146 to a central assembly 140 such that the 
computer/database assembly 140 may still collect/retrieve 
data from the one or more apheresis assemblies 10 even if 
the central assembly 140 is not used to program the respec- 
tive machines 10. However, where a central computing/ 
database assembly 140 is employed as preferred herein, this 
donor-related data and/or initial procedure order is prefer- 
ably generated by the central computer/database assembly 
140 and then transferred to one of the apheresis machines 10 
(via an RS/232 or other similar interface, among other 
communications options such as energy wave communica- 
tions, inter alia (see further descriptions below)). In either 
event, the operator is preferably provided with one or more 
data manipulation or optimization options, whether through 
the central data manipulation device 144 of a centralized 
computing/data storage assembly 140 or the data manipu- 
lation capabilities of the apheresis machines 10 themselves. 
Note the data manipulation and/or optimization options 
provided by a central assembly 140 may provide a different 
set of process control parameters than an initial procedure 
order that might result from data entered manually on the 
apheresis machine 10 because the data manipulation and/or 
optimization on a central assembly 140 may be based upon 
one or more previously specified and central database stored 
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conditions/goals (e.g., input blood component yield, input 
procedure time) and one or more particular derivations for 
the process control parameters. Generally, more flexible 
options would be available from a central server system 140 
than those previously available on discrete machines 10. 
Moreover, if an optimization option is selected at the central 
server 140, a manually-entered procedure order may be 
modified to reflect the results of such an optimization and the 
collection procedure may be initializedVreinitialized with the 
results of the optimization (i.e., the collection procedure 
could be reinitialized in the less preferred case of an opti- 
mization which is performed after the collection procedure 
has been started and such a case is referred to as a down- 
stream optimization). The collection procedure may then 
thereafter be performed by the respective blood component 
collection device 10. 

[0062] The concept of optimization here generally refers 
to achieving the maximum or best product output depending 
upon certain circumstances (e.g., obtaining the most product 
in a certain specified time or achieving a specific yield in the 
fastest time). On the other hand, the concept of data manipu- 
lation is more generally here intended to have a similar yet 
less exacting connotation, such that perhaps the best or 
maximum output may, but will not necessarily be the result. 
Thus, data manipulation is here intended to encompass 
optimization calculations in addition to providing perhaps 
less than optimum but still high efficiency results depending 
on certain further combinations of criteria. Thus, data 
manipulation is intended to generate more and/or perhaps 
better options to the blood donation center. For example, 
blood centers may prefer or determine to require certain 
combinations of products from certain blood type donors 14 
(see FIG. IB); then the blood center 1000 can prioritize this 
in the computer/database 140 so that those donors will 
donate those combinations even if the particular yields or 
donation times are not fully optimized according to the 
concept of optimization set forth above. Thus, yield or time 
optimization can be made secondary to other data require- 
ments and/or manipulations. Note also that optimization 
and/or manipulation may be performed without requiring the 
central system 140 to collect/retrieve data from the various 
apheresis assemblies 10. Thus, communications may be 
made only one-way to (or from) the apheresis assemblies 10. 
Further, a preferred purpose for performing the optimization 
and/or manipulation functions centrally is to allow selection 
of the donation procedure prior to connection of a donor to 
a machine 10; thus, a particular product or products and the 
corresponding tubing set (if there are distinctive such sets) 
may be selected prior to machine set-up and donor connec- 
tion. Also it could prove that the donor may not be able to 
provide a useful donation (for the end recipient/patient 15; 
see FIG. IB), and this could thus be determined prior to 
machine set-up and/or donor connection. 
[0063] Nevertheless, before describing the preferred 
manipulation/optimization processes of the present inven- 
tion in any further detail (see description relative to FIGS. 
7-10, below), two further, non-exhaustive alternative system 
embodiments will first be described. Referring first to FIG. 
1C, an alternative centralized computing, communication 
and data storage assembly 140A is shown. Assembly 140A 
includes a central station, here referred to as a central data 
server 148A, which may be substantially like the central 
server 148 in FIG. 1A, at least preferably in primary 
function. At least a storage medium/database 142A and 



preferably also a data manipulation device 144A, each again 
substantially like those described relative to the embodiment 
of FIG. 1A are also preferably disposed within the central 
server 148A of FIG. 1C. However, in the embodiment of 
FIG. 1C, the communication sub-system identified gener- 
ally by the respective reference numerals 146Aand 146B, is 
shown as preferred here discrete therefrom, in two general 
sub-parts, referred to respectively as the machine network 
146A and the client network 146B. 

[0064] Machine network 146A preferably includes a net- 
work terminal server 1210 with a connection 1212 between 
the server 148A and the terminal server 1210. Respective 
connections 1215 are also shown as disposed between 
terminal server 1210 and each of the separation/collection 
machines 10. Connections 1212 and 1215 may typically be 
RS/232 cable-type connections, or other alternative data 
communication connections may be used including such 
options as radio, microwave or other electromagnetic wave 
communication systems (not specifically shown). Note that 
other separation/collection machines/systems, such as sys- 
tems 10A, 10B, 10C and 10D (from FIG. IB) may also be 
connected to/through the illustrated terminal server 1210 or 
a further discrete server (not shown). 

[0065] A similar, though preferably discrete, network ter- 
minal server 1220 is also shown in FIG. 1C to illustrate a 
preferred communication sub-system for the client network 
146B. A connection 1222 between the central server 148A 
and the terminal server 1220 is also shown, as are respective 
connections 1225 from the terminal server 1220 to one or 
more data input/output/ manipulation stations 149C (two 
shown here). Connections 1222 and 1225 may here also 
typically be RS/232 cable-type connections, or take other 
data communication forms including, for example, energy 
wave communication forms. Note also that other devices 
(not shown) might also be connected or connectable 
to/through the illustrated server 1220, as for example, one or 
more printers (not shown) or other accessory devices. Note, 
stations 149C may contain, as above, one or more various 
input/output devices such as keyboards, mice and/or screens 
(as shown) or otherwise (barcode readers, digital cameras, 
etc., not shown). Moreover, as decentralized stations, these 
assemblies may also generally include computing devices 
and/or capabilities such as may be included in standard 
desktop or laptop computers, including the stations 148B as 
shown, and potentially data storage/memory and/or data 
manipulation devices and/or software along with potential 
resident communications devices and/or software. 

[0066] Separating the machine network server 146A from 
the terminal network server 146B allows for isolating and/or 
protecting communications therebetween, as may be 
desired. Thus, the respective servers may have on one side, 
a network connection to the central server 148A using 
discrete I/P (Internet Protocol) address information, and on 
the other side, RS/232-type connections to the respective 
end devices (machines 10, and/or input/output devices 
149C, e.g.). In this fashion then, each network may be kept 
private from each other such that the I/P's are essentially 
hidden from each other by the central server 148A. A 
firewall communication protection setup as known in the art 
may thus be established. 

[0067] A further alternative communication sub-system 
146C is shown in FIG. ID. Sub-system 146C generally 
includes a network terminal server 1230 with respective 
connections 1232 which connect respective central servers 
148C to network terminal server 1230. RS/232 or other 
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communication connections (as above) may be used here as 
well. In this way, two or more centralized servers 148C may 
communicate data with each other. Thus, central servers in 
two or more physically separate clinics may communicate 
with each other. Such a system may also be used for 
communication with other information systems (blood cen- 
ter information systems or hospital information systems) 
such as is schematically shown in FIG. IB. Other similar 
communications can also be made in this way, as for 
example to help or maintenance centers (not shown), as 
described below. Firewall types of communication protec- 
tions may also be set up here, such as was described above. 
Thus, network connections can be made between each 
central server 148C and the network terminal server 1230; 
whereas RS/232-type communications can be established 
elsewhere. Note, all variations of system 140 may include 
communications connection^) of many different sorts 
which allow each particular device to communicate with 
other devices. RS/232 communications connection^) as 
described, are only examples of such communication media. 
Communication media may typically embody, be embodied 
in or otherwise be capable of interacting with and/or through 
computer readable instructions, data structures, program 
modules or other data in a modulated data signal such as a 
carrier wave or other transport mechanism and include any 
information delivery media. The term modulated data signal 
may include a signal that has one or more of its character- 
istics set or changed in such a manner as to encode infor- 
mation in the signal. By way of example, and not limitation, 
communication media may include wired media such as a 
wired network or direct-wired connection, and wireless 
media such as acoustic, RF, infrared and other wireless 
media. The term computer readable media as used herein 
preferably includes both storage media and communication 
media. 

[0068] A more detailed description of the preferred steps 
for using the present preferred system will now be set forth. 
In FIGS. 2A-2I, inter alia; use of the centralized computing/ 
data retrieval assembly is shown in more detail. First, FIG. 
2A depicts an exemplary display page or screen 201 which 
may be the first such screen displayed on the output monitor 
display screen 200 (see, e.g. FIG. 1A) of the centralized 
computing/data storage assembly or system 140 when the 
software thereof is initially accessed. A more, rather blank, 
screen (not shown) may be used as an initial screen upon 
startup, as described below. As can be seen in display screen 
201 generally, the initial donor information may be gathered 
here, such as for example the donor's name (last and/or 
first), and/or the donor's identification (ID) number or like 
identifier (if used), and/or the donor's telephone number or 
other identification data (also if used, not shown). Data entry 
fields for these types of data may be seen in the main work 
area 202. These are several examples of possible initial 
identifiers among numerous others which could be alterna- 
tively substituted herein. 

[0069] Moreover, as mentioned this could be the first 
display screen to be shown upon software initialization, or 
other alternatives (not shown) could be simply used pre- 
liminarily hereto by way of introduction to this or a like 
display 201. In any event, some display is preferably used as 
the starting point for data entry (and/or search, if the data 
were previously entered or imported from another system) 
for use with a particular donor, and for the sake of conven- 
tion, display 201 will be used in this role for this description 



of the preferred embodiment. Note also, that as shown in 
FIG. 2A, disposed next to the main work area 202 (with 
sub-areas 203 and 204 as will be described below) is a 
procedure icon selection area 205 which is depicted along a 
vertical portion of the left-hand side of display 201. In it, five 
icons 207, 208, 209, 210, and 211 are currently shown, 
though either more or fewer such icons could be used as may 
be desired. 

[0070] A description of the preferred general overall pro- 
cedural flow will be set forth starting with particular refer- 
ence to the procedure icon bar 205 on the left side of the 
display screen 201. 

[0071] As an initial step or sub-procedure, the Select 
Donor icon 207 represents the performance of several func- 
tions generally described as follows. First is a Greet Donor 
function wherein the system operator may verify and/or add 
a new donor record to the system database 142, and check-in 
a donor into the system 140 (either by data entry directly into 
this application or via automatic transfer of data from a 
discrete blood bank information system). Thus, the operator 
may perform Donor Entry/Edit functions to enter or modify 
a donor record in the database (see e.g., FIGS. 2B-2I, as 
described below). This may also include capturing a donor 
image using a digital camera to take the donor's photo (this 
functionality may also or alternatively be part of the Prepare 
Procedure Wizard process; see below). And, this may 
include use of a barcode reader to enter barcoded data such 
as the donor ID, etc. (Note: this data input functionality may 
also be part of other processes in this system such as the 
Prepare Procedure Wizard (entering barcoded unit number) 
and/or the Finalize Procedure Record (entering barcoded lot 
number/data for supplies).) 

[0072] After the data entry/verification, the next general 
step would preferably be to Prepare the Procedure for 
component collection as indicated by the second icon 208 in 
bar 205 as shown in FIGS. 2A and 3A, inter alia. This 
preferably involves using a Prepare Procedure sub-proce- 
dure or software wizard to record further donor information 
and select the procedure to be run on the donor prepared as 
set forth above (see description relative to FIGS. 3A-3F, 
below). 

[0073] Next, the operator preferably uses the Assign 
Machine icon 209 to access the sub-procedure for assigning 
the donor to a particular apheresis collection system 10. 
More details of this process are described below with 
particular respect to FIGS. 4A and 4B. 

[0074] As shown generally in FIG. 5A, the central system 
140 may be used for monitoring the procedure/machine 
status after the assignment of a donor to a particular 
machine. An icon 210 (FIGS. 2A and 5A) is preferably 
included for accessing this functionality in the left-hand 
procedure icon area 205. Screen 501 (FIG. 5A) reflects the 
first step in such a monitoring sub-procedure. Finalization of 
the Procedure Record may also be performed here, wherein 
the operator may enter procedure data, including operator 
roles and supplies entries. (Note: this record finalization 
functionality may also be part of the Select Procedure 
process below.) 

[0075] Another optional step in the overall procedure 
shown in FIGS. 2A and 6A by the icon 211 is the Select 
Procedure sub-procedure where the operator may search for 
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and select a procedure (either active, pending, or finalized). 
A screen 601 such as shown in FIG. 6A may then be 
displayed (as described in further detail below). The opera- 
tor will then be able to enter lab results by entering proce- 
dure product volume/quality information returned from the 
lab. The operator may finally prepare a Report on the 
Procedure by generating procedure or donor or production 
reports. 

[0076] It ought to be noted that the various sub-procedures 
identified by the respective icons 207-211 can be selected at 
any time in the overall procedure to view, input or modify 
particular desired information. As an example, but not to be 
considered in any way as a limitation, the assign machine 
icon 209 could be selected at anytime to view the list of 
available and/or assigned machines 10. However, it should 
be noted that certain functionalities may thus be unavailable 
if an icon 207-211 is selected without having completed a 
previous sub-procedure. For example, upon selection of the 
assign machine icon 209 as suggested here, the assignment 
function will not be available unless at least one donor has 
been processed though the Prepare Procedure sub-procedure 
(see description, below). In such a case, where no donor has 
yet been so processed, there would not appear any donor 
icon in the donor assignment queue of screen 401 (FIG. 4A), 
even if the available and assigned machines 10 may be 
shown in the machine list. Similar functionalities preferably 
requiring pre-completed sub-procedures (thus building on 
previous module completion^)) are identified throughout 
the below descriptions. 

[0077] Although not a part of the general run procedure 
(and thus not involving or resulting from the clicking of 
icons in the procedure icon area 205), Administration Tasks 
(extra security being preferably required to access these 
options) may generally include: Setting Up the Application 
including setting default values; setting the apheresis 
machine configurations) including creating and/or modify- 
ing apheresis collection system configurations; Defining 
Products including establishing an unlimited number of 
product definitions; Defining Procedures including estab- 
lishing an unlimited number of procedure definitions (com- 
binations of product definitions); Defining Focus lists 
including establishing an unlimited number of procedure 
focus lists (prioritization of procedure definitions); Perform- 
ing Database Administration including managing and main- 
taining the data stored within the central database; and 
Blood Product Prediction wherein a blood product forecast- 
ing report may be generated. 

[0078] Returning now to FIG- 2A, a more detailed 
description of the preferred overall procedure will now be 
set forth. In an initial start-up mode of software initializa- 
tion, the main work area 202 could be adapted to display a 
preliminary display screen (not shown) which has no active 
work spaces. Then, after log-in (see below), the operator 
could be forced to select an icon from a menu list and/or 
from the left-hand procedure icon selection area or bar 205 
in order to initialize the overall procedure. As an example, 
the operator could first select the select donor icon 207 with 
a computer screen cursor or pointer (not shown) and click 
the enter or mouse button (neither shown) as is known in the 
art of standard desktop or laptop computer, Windows®- 
based or like software applications. This selection could then 
bring up the shown display 201 for beginning a donor 
check-in procedure. A few further alternatives for use in 



start-up (as well as throughout operation) may be found in 
the toolbars located as shown horizontally along the upper 
portion of the display 201. These are toolbars much like 
those used in a plurality of computer Windows®-type soft- 
ware applications with numerous functional similarities and 
specific distinctions as described herein. For example, the 
software start-up to the initial working display may also be 
achieved by selecting the "Tasks" menu heading 216 in the 
top level menu toolbar 215 and then selecting the appropri- 
ate "open" file command (not shown) or other like com- 
mands as are generally known in the art. Or, similarly, a 
small icon toolbar 217 may be configured to be used for 
initiating software procedures, as may also be generally 
known in the art. Other menu headings and/or icons (not 
shown) in toolbars 215 and/or 217 (or otherwise, not shown) 
may be used for other functions in startup or otherwise. 
[0079] A third toolbar 220 may further be used in or even 
prior to software initialization or it may not be opened until 
the main work area 202 has been opened. The third toolbar 
220 as shown and preferred herein has a location for the 
typing of a name or other identifier which may be used to 
begin the process of either data entry for new records or a 
search for existing records. This third toolbar 220 is pref- 
erably used for identifying the operator of the system, such 
identification being useful for logging-in and/or assessing 
the operator's level of security clearance, inter alia 
(described below). Thus, it is preferred that this operation of 
logging-in the operator be completed first. Further, it is 
preferred that a system administrator have previously estab- 
lished authorized users, with log-in names and optional 
passwords. The log-in names may then be typed in the blank 
space in tool bar 220, or the down arrow may be selected and 
clicked to reveal the list of authorized users to be selected. 
Once a user log-in name is entered, then a pop-up dialog 
box/window (not shown) may be made to appear to prompt 
entry of an appropriate password. Note, password and/or 
user log-in names may be made editable via such a pop-up 
dialog box/window (not shown) or may be restricted to 
editing by a system administrator. Further similar options 
may also be used for these initialization procedures as may 
be known in Windows® or Windows®-like environments. 
[0080] Returning now to the main work area 202 of the 
display screen 201, two sub-areas 203 and 204 are shown in 
which data may be entered or displayed. First, as shown in 
sub-area 203, data concerning the identity of the donor to be 
checked-in may be entered in order to begin the donation 
process. The computer/database system 140 may then be 
made to search its database 142 (by selection of the search 
button 218 by the operator) to determine whether this 
particular donor has been previously entered in the system. 
If so, the system 140 returns the results of that search in the 
search results sub-area 204. Note that the search may be 
made dependent on any of the criteria set forth in the first 
sub-area 203 (or others not shown herein but alternatively 
usable herewith). Also, the search mechanism may be 
adapted to search wild cards and/or truncated terms or list 
various short forms for further search as these and other 
search capabilities are known in the art. As such, when typed 
into the proper field, this display screen simply calls up a 
donor from the existing database if such a donor exists 
therein. A search/query format may be used wherein typing 
an alphabetical initial will call up into the results window 
204 all donor names beginning with that initial. The operator 
may then double click on a listed name to select and call up 
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the next preferred screen (see FIG. 2B, the donor entry/edit 
screen 221), which contains greater detailed donor informa- 
tion as will be described below. 

[0081] First, however, several other graphical buttons are 
shown in the main work area 202 of FIG. 2A and may be 
used to perform various functions. For example, below the 
work sub-area 204 are examples of three buttons which 
could be set forth on this or any other alternative display 
screen used herein. In this example, the three buttons here 
are the "new" button 212, the "select" button 213 and the 
"help" button 214. The "new" button 212 could be used to 
toggle to a fresh search page like this one 201 shown without 
any information in any of the fields (name, ID, or results). 
Alternatively, the "new" button 212 could allow for either 
new data entry editing directly in the fields shown here in 
screen 201, or could be used to call up a secondary display 
screen, such as the Donor Entry/Edit screen 221 shown in 
FIG. 2B (described below). Such a "new" screen would 
preferably have empty fields to allow for new donor infor- 
mation data entry. Note, the "new" button 212 is shown in 
active, darkened mode in FIG. 2A as compared to the other 
"grayed-out" buttons 213 and 214. This means it is active as 
shown (and as would be understood to those knowledgeable 
in the art of common, conventional Windows® and the like 
software applications). It is active as shown when it may be 
desirable to enter new data records into the system. The 
"grayed-out""select" button 213, on the other hand, is 
inactive until a search result record is displayed in sub-area 
204. When such a record is made available, button 213 
would be made active and darken in style such as the other 
active buttons shown here. The "select" button 213 provides 
for the selection of a donor data record to be verified and/or 
modified for preparation of a collection procedure. This 
functionality as well as that of the "help" button 214 is 
described in greater detail below. 

[0082] As next shown by the donor data entry/edit screen 
221 in FIG. 2B, data can be either manually input into the 
computer/database system 140 by typing into the corre- 
sponding fields such as will be described further below. Or, 
any appropriate data input can be performed with an alter- 
native input system such as, for example, a bar code reader 
(not shown), or input from other computerized information 
systems as will be described below and/or become obvious 
to those skilled in the art. If using a bar code reader, a donor 
may be given a donor identification (ID) card which may 
have a bar code imprinted thereon which represents that 
particular donor's data. Then, an optical reader (not shown) 
can be used by the operator to read the bar code information 
from the card to fill in the donor data fields shown in FIGS. 
2B-2I. The other previously introduced alternative input 
process would be in taking advantage of other pre-existing 
database/information systems which may already contain 
the appropriate donor data. Thus, the present computer/ 
database system 140 may be disposed in data communica- 
tion relationship with one or more such pre-existing systems 
and simply upload the desired data therefrom. Thus, the 
fields such as those shown in FIG. 2B, et al., can be 
automatically populated from the blood center's manage- 
ment information system (e.g., Wyndgate, MAK, etc.). In 
this situation, the reception portion of the data entry process 
(i.e., initial data entry and/or verification) could take place 
entirely on the blood center receptionist's computer in the 
corresponding Wyndgate or MAK (or like) system. This 
information may then be retrieved by and/or forwarded to 



the computer/database system 140 to populate the fields 
such as those shown in the display 221 of FIG. 2B. This 
display 221 may be referred to hereafter as the Donor 
Entry/Edit screen 221 and may, in the three-room model 
initially be called up in the what may be referred to as the 
"Reception" room. This three room model will now be 
briefly described. 

[0083] There may be considered three main data input/ 
verification points in a collection process. At the first point, 
hereafter referred to as "Reception," the donor is checked 
into the overall process. Under a scenario of data connec- 
tivity between the central computing/database system 140 
and a blood bank information system, the "Reception" 
room/step may be handled through the blood bank informa- 
tion system and the needed donor data may then be auto- 
matically transmitted (downloaded or uploaded or other- 
wise) into the central system 140 as described above. With 
this connectivity between the blood center information sys- 
tem and the central system 140, the historical donor data 
(which may be batch file loaded into the central system 140 
periodically) may also be called up and the donor may then 
be assigned to the second room, hereinafter also called the 
"Screening Room " In the screening room the donor infor- 
mation may be retrieved and displayed and several prefer- 
able pieces of lab data may be input for purposes of selecting 
the proper/preferred collection procedure to be performed. A 
donation unit number may also be assigned at this point. The 
central system 140 may, but preferably does not, hold 
confidential donor information influencing potential defer- 
ral; this information would preferably reside only in the 
blood bank information system. The central system 140 is 
preferably only concerned with the collection process. In 
either the "screening room" or the third room, hereinafter 
also called the "Donation Room," the donor may be assigned 
to a particular apheresis machine. The procedures performed 
in the donation room may also include recording other data 
about the procedure such as recording the identification 
numbers associated with the disposable tubing set. Once the 
donor is assigned to a machine, the central system 140 
would preferably go into a monitor-only mode relative to 
that donor and that machine for monitoring and/or recording 
any and/or all events in the procedure. More details hereon 
are provided below. 

[0084] Returning to the donor entry/edit screen 221 of 
FIG. 2B, further details concerning some of the specific, 
preferred fields, tabs, buttons, etc. shown on screen 221 in 
FIG. 2B will now be set forth. 

[0085] As mentioned, new donor records may be created 
using screen 221, and pre-existing records may also be 
edited/modified here. A primary difference in creating new 
records versus modifying existing ones lies in the fact that 
the fields shown in FIG. 2B will be empty prior to entry of 
new record information, as opposed to having been popu- 
lated by previously entered (or imported) data in the modi- 
fication sense. As shown in FIG. 2B, the data fields are 
primarily populated thus generally signifying either a data 
import or previous donor record entry situation. 

[0086] Primarily donor identification data/information, 
such as the donor's name and/or ID, may be entered/edited 
in the fields disposed preferably in an upper substantially 
fixed area 222 of screen 221. However, if this data has come 
from a previously entered record, the fields in area 222 are 
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preferably "inactive" as shown by being "grayed-out." Thus, 
these fields would preferably not be editable directly, rather 
would be editable otherwise as described below. Other 
information about a particular donor may then be entered/ 
edited in corresponding fields appearing with respective tabs 
in the lower data area 224. For example, donor demograph- 
ics information may be entered/edited in corresponding 
fields under the "Demographics" tab 231 as shown in FIG. 
2B. Other general information such as gender or date of 
birth, inter alia, would preferably be enterable/editable under 
the "General" tab 241 (see FIG. 2C). Blood type, CMV, 
(cytomegalovirus) and HLA (Human Leukocyte Antigen) 
type, inter alia could be entered/edited under the "History" 
tab 251 (FIG. 2D). A "Comments" tab 261 (FIG. 2E) could 
be selected and used for entry of comments about the donor. 
Allergy information could be entered or edited under an 
"Allergies" tab 271 (see FIG. 2F). Donor status data could 
be entered and/or edited under a "Status" tab 281 (FIG. 2G) 
including such data as, for example, last procedure date, 
numbers of donations given, over what period of time, etc. 
Other tabs, such as a "Blood Loss History" tab 291 (FIG. 
2H) and/or a "Procedure History" tab 299 (FIG. 21) could 
also be used for separate entry of such information. Note, 
separate pop-up dialog boxes or other alternative screen 
styles or types (none shown) may be used for prompting for 
and entering/editing these types of information. 

[0087] Note, the information shown and described here in 
screen 221 may alternatively be optional or mandatory, 
depending on the desires of the ultimate user; here, usually 
a blood center. That is, the standard operating procedures 
(SOP's) of the blood center may be implemented herein to 
make certain information optional or mandatory, as desired. 
However, certain information, whether listed here (under the 
Donor Entry/Edit screen 221) or entered elsewhere (see the 
Prepare Procedure functionality, described below) may be 
required by the blood separation/collection assembly 10 
prior to initiation and/or completion of a separation/collec- 
tion procedure. Examples of such information may be gen- 
der, height, weight, blood type, and/or pre-count (platelets 
and/or hematocrit) information (again, see the Prepare Pro- 
cedure, below). As such, some of this information (e.g., 
height/weight) would only be enterable/editable, as pre- 
ferred here, in the procedure preparation portion of the 
overall process (see below). 

[0088] Moreover, as introduced above, all, most, or at least 
the information required by the blood center may be entered 
or have been entered previously into the blood center's 
separate (but communicatively-linked) information system 
(not separately shown, but see FIG. IB). Such an informa- 
tion system is separate from the present invention, although 
these systems may be made to communicate with each other. 
Thus, such information may be entered into the blood center 
information system, preferably according to the standard 
operating procedures (SOP's) of the blood center, and then 
this information may be transferred (downloaded or 
uploaded, or otherwise) to the central system 140 of the 
present invention. This information would then populate the 
respective fields shown and/or described here relative to the 
Donor Entry/Edit screen 221. An operator of the present 
system may then use screen 221 to merely verify the 
accuracy and/or completeness of this information shown on 
screen 221 prior to checking-in the donor for the present 
collection procedure. 



[0089] In a presently preferred embodiment, when a blood 
center information system is used, the transmission of this 
general sort of donor identification, demographics and com- 
mentary information, inter alia, is one-way from the blood 
center information system to the central server system 140 
of the present invention, primarily to maintain SOP's on 
which types of donor information a blood center may wish 
to capture. Thus, the operator may continue to operate at 
reception in a fashion unchanged from before introduction 
of the present invention. 

[0090] Nevertheless, these donor identification data may 
also be transmitted both ways; namely, from the blood center 
information system to the central server 140 and/or back to 
the blood center information system from the central server 
140. In such an option, these data may be entered/edited in 
either system and then be made to update the records of the 
other system. Note, these donor data communications are 
discussed here only in terms of the general donor data; not 
necessarily including feedback information about the results 
of any particular collection procedure. Such procedural data 
communications are also considered within the present 
invention, but are discussed further below. 

[0091] First however, more particular descriptions of the 
preferred data to be entered/edited in screen 221 will now be 
described. 

[0092] As mentioned, in the Demographics tab 231, the 
operator may enter/modify the donor's national ID, address 
and telephone number as shown in FIG. 2B. Then, after 
selecting the General tab 241, the following information 
may preferably be entered/edited: Gender (Male or Female, 
neither of which preferably selected by default); Date of 
Birth (which can be typed in text box or selected using 
pop-up calendar); Ethnic Background (preferably available 
via a drop-down list which is editable by selection only, and 
is preferably created by the System Administrator); and 
Donor Picture (the default is preferably a generic, genderless 
icon; however, if a gender is selected using one of the 
Gender radio buttons, this icon preferably changes to a 
gender-specific icon the next time the donor record is 
accessed, provided the operator saved the data before clos- 
ing the dialog box). The operator can optionally click 
Update Picture to take donor's photo using an optionally 
attached digital camera. 

[0093] The operator may then optionally click the Donor 
History tab 251 (FIG. 2D) to view/modify procedure history 
data for this donor. This tab 251 may contain the following 
information: Blood Type, CMV, HLA, Hematocrit, and/or 
Platelet Count. More specifically, the Blood Type may 
include A+, A-, B+, B-, AB+, AB-, O+, 0-, or Unknown; 
preferably accessible via a drop-down list, editable by 
selection only; default is preferably Unknown. The CMV 
Status includes Unknown, Positive, and Negative Radio 
buttons options; the default is preferably Unknown. HLA 
Typing options are as follows: the operator may select the 
HLA Tested check box if HLA testing has been done for this 
donor; or left unchecked by default. And the A, B, C, D 
check boxes are disabled unless the HLA Tested check box 
is selected. Once HLA Tested is selected, the operator can 
select one or more HLA-type check boxes (A, B, C, and/or 
D). The Last Hematocrit and the Last Platelet Count are 
preferably non-editable, generally pre-populated fields from 
past procedure data or external blood bank information 
system, if available. 
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[0094] The operator may then also optionally click the 
Comments tab 261 (FIG. 2E) to enter/view free-form com- 
ments about the donor. To add a comment, the operator 
clicks the Add Comment button 262. A separate Enter Donor 
Comment pop-up dialog box (not shown) may then appear, 
or comments may be made enterable/editable within the 
work space 263, shown. The operator may then enter a 
comment in the text box. Note that a comment is preferably 
not saved in the donor record until the operator clicks the 
Apply or OK button 229 or 230 in the Donor Entry/Edit 
dialog box 221 (see more details below). 

[0095] The operator may then optionally click the Aller- 
gies tab 271 (FIG. 2F) to enter/view donor allergies and 
associated comments. To view the comments about a spe- 
cific allergy, the operator clicks the allergy in the Donor 
Allergies list; associated comments for this allergy appear in 
a Donor Allergy Comment box. To add an allergy, the 
operator may click the Add Allergy button. An Enter Donor 
Allergy pop-up dialog box (not shown) may then appear. A 
listing of allergies (preferably non-editable and created by 
the System Administrator) may be made to appear in such a 
dialog box and the operator may optionally enter a comment 
pertaining to that allergy in the Allergy Comment box. Note 
that an allergy is preferably not saved in the donor record 
until the operator clicks the Apply or OK button 229 or 230 
in the Donor Entry/Edit dialog box 221 (see details below) 

[0096] The operator may also decide to remove an allergy 
from the Donor Allergies list. The operator may then click 
the allergy in the Donor Allergies list, and then click the 
Remove Allergy button. The allergy is removed from the 
displayed list; however, the allergy is not permanently 
removed from the donor record until the operator then clicks 
Apply or OK button 229 or 230. The operator may decide to 
enter additional comments for an allergy currently in the 
Donor Allergies list. The operator clicks the allergy in the 
Donor Allergies list, and then clicks the Add Comment 
button. An Allergy Comment dialog box (not shown) may be 
made to appear. The operator can then enter a comment and 
click an OK option. The Donor Entry/Edit dialog box 221 
reappears, still showing the Allergies tab 271 (FIG. 2F). The 
allergy listing in the Donor Allergies list is updated to show 
the new comment. The date and time the comment was 
created, as well as the user ID for the user who was logged 
on when the comment was created, will preferably appear 
with the comment in the Donor Allergy Comment box. 

[0097] The operator may then optionally click the Status 
tab 281 (FIG. 2G) to enter/view the following donor status 
information: Donor Status — Active or Inactive; Donor Cat- 
egory (a drop-down list, preferably created by the System 
Administrator); Donor Since Date — date the donor started 
donating (preferably defaults to first procedure date, if not 
modified, which can be typed in text box or selected using 
a pop-up calendar); Last Visit Date — last date the donor 
attempted to donate (defaults from system records, prefer- 
ably non-editable except by the System Administrator); Last 
Procedure Date — the last date the donor actually did donate 
(default from system records, non-editable except by the 
System Administrator); Last Contact Date — last date that the 
center contacted the donor (can be typed in text box or 
selected using pop-up calendar, default is preferably the 
current date). 



[0098] The operator may then optionally click the Blood 
Loss History tab 291 (FIG. 2H) to view the total volume of 
blood the donor has lost from apheresis (not whole blood) 
activities for the previous 12-month period. All of the data 
in this tab is preferably non-editable in this module. It is 
downloaded as run data from the apheresis collection system 
10 (preferably a Trima® system 10) for procedures run for 
this donor, and/or entered by an operator during procedure 
finalization (see below). The tab 291 preferably shows the 
Total Blood Loss the total volume (preferably in milliliters) 
of blood the donor has lost from apheresis (not whole blood) 
activities for the previous 12-month period); and a Proce- 
dure table which shows blood loss for apheresis procedures 
for which a procedure record exists in the central server 
system 140. Each procedure is preferably listed in a separate 
row in the table. The operator may need to scroll horizon- 
tally or vertically to view some of the data. For each 
procedure, the table preferably shows the following: 

[0099] Procedure Date — The date the procedure was 
run. 

[0100] Product RBC— The volume of RBC product 
collected during the procedure (total RBC volume 
less anticoagulant volume). This information is pref- 
erably determined based on the procedure that was 
run and the donor's hematocrit. 

[0101] Sample RBC— The volume of sample RBCs 
collected during the procedure. This volume is either 
the default value set by the Administrator during 
system setup or a value entered by an operator during 
procedure finalization, according to the facility's 
SOPs (see the Finalize Procedure Record description 
below). 

[0102] Residual RBC— The volume of residual 
RBCs remaining in the tubing set after the proce- 
dure. This information is determined based on the 
tubing set type, the procedure that was run, the 
donor's hematocrit, and whether or not rinseback 
was completed for the procedure. 

[0103] Other RBC— Any other RBC volume (for 
example, estimated volume of a spill), entered by the 
operator in the Finalize Procedure Information dia- 
log box, Blood Loss tab, according to the facility's 
SOPs. (see the Finalize Procedure Record descrip- 
tion below). 

[0104] Product Plasma — The volume of plasma 
product collected during the procedure (total plasma 
volume less anticoagulant volume). The information 
is determined based on the procedure that was run 
and the donor's hematocrit. 

[0105] Sample Plasma (not shown in FIG. 2H; 
scrolled off the right side of the screen) — The vol- 
ume of sample plasma collected during the proce- 
dure. This volume is either the default value set by 
the Administrator during system setup, or a value 
entered by an operator during procedure finalization, 
according to the facility's SOP's (see the Finalize 
Procedure Record description below). 

[0106] Residual Plasma (not shown in FIG. 2H; 
scrolled off the right side of the screen)— The vol- 
ume of residual plasma remaining in the tubing set 
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after the procedure. This information is determined 
based on the tubing set type, the procedure that was 
run, the donor's hematocrit, and whether or not 
rinse back was completed for the procedure. 

[0107] Other Plasma (not shown in FIG. 2H; scrolled 
off the right side of the screen) — Any other plasma 
volume (for example, estimated volume of a spill), 
entered by the operator in the Finalize Procedure 
Information dialog box, Blood Loss tab, according to 
the facility's SOPs. (see the Finalize Procedure 
Record description below). 

[0108] The operator may then optionally click the Proce- 
dure History tab 299 to view product information for all 
procedures run for this donor since the donor record was 
created in the present system 140. The tab 299 shows 
product information only for apheresis procedures for which 
a procedure record exists in the database 142. All of the data 
in this tab is preferably non-editable. It is downloaded from 
the apheresis system (preferably a Trima® system) 10 run 
data for procedures run for this donor. The operator may 
need to scroll horizontally or vertically to view some of the 
data. For each procedure, this tab 299 preferably shows the 
following: 

[0109] Procedure Date — The date the procedure was 
run. 

[0110] Platelet Yield— The yield of platelets col- 
lected during the procedure. 

[0111] Plasma Volume — The volume of plasma col- 
lected during the procedure (plasma product volume 
plus anticoagulant volume). 

[0112] RBC Volume— The volume of RBCs col- 
lected during the procedure (RBC product volume 
plus anticoagulant volume). 

[0113] Various alternative data entry/editing actions may 
also be preferred. For example, at any time while using the 
Donor Entry/Edit dialog box 221, the operator may click the 
Apply button 229 (see FIGS. 2B-2F, e.g.) to save all to-date 
changes to the donor record, without exiting the dialog box. 
Similarly, at any time while using the Donor Entry/Edit 
dialog box 221, the operator may click the Cancel button 
228 to cancel the current entry session. The system 140 may 
then prompt the operator to confirm the cancellation. If 
cancellation is confirmed, the system may lose all unsaved 
changes and closes the Donor Entry/Edit dialog box 221. A 
Help button 227 is preferably also provided to present a 
corresponding help screen (not shown) when desired. 

[0114] If the facility determines that a donor record no 
longer needs to be in the central database 142, the record can 
be permanently removed. This option is preferably only 
available when an operator with a high level clearance such 
as a System Administrator user role or the like is logged on 
to the system. This Administrator or high level operator may 
then search for and display the donor record in the Donor 
Entry/Edit dialog box 221, as described and then click the 
Remove button 226 (see e.g., FIG. 2B). A warning may first 
be made to appear, informing the operator that the record 
will be permanently removed from the database 142. If 
removal is still desired a Yes confirmation button (not 
shown) may be selected. The following may then occur: 1) 
both the warning message and the Donor Entry/Edit dialog 



box 221 may be closed; 2) the Search Results box 204 in the 
Select Donor task window 201 (see FIG. 2A) would no 
longer show a listing for the removed donor; 3) the donor 
record would preferably be permanently removed from the 
database; and/or 4) an internal record for this donor may be 
retained elsewhere in the system for reporting reasons. 

[0115] Moreover, at any time while using the Donor 
Entry/Edit dialog box 221, the operator may change the 
donor's name, while retaining the current donor ID. To do 
so, the operator would preferably click the Edit Donor Name 
button 223 (see e.g., FIG. 2B) in the Donor Entry/Edit 
dialog box 221. An Edit Donor Name dialog box (not 
shown) would preferably be made to appear, displaying all 
previous names used by the donor, as well as the date the 
name was changed and the operator who was logged on to 
the system when the name change was made. The operator 
may then enter a new name for the donor in the Last Name, 
First Name, and/or Middle Name boxes, and conclude with 
an OK option (not shown). The Donor Entry/Edit dialog box 
221 would then reappear, showing the changed name. The 
operator can still also decide to not change the name by 
selecting a Cancel option in the Edit Donor Name dialog box 
(not shown) to retain the current donor name; whereby, the 
Donor Entry/Edit dialog box 221 would reappear, showing 
the unchanged name. Note that a changed name is not saved 
in the donor record until the operator clicks the Apply or OK 
button 229 or 230 in the Donor Entry/Edit dialog box 221. 

[0116] Similarly, at any time while using the Donor Entry/ 
Edit dialog box 221, the operator may change the donor's 
ID, while retaining the current donor name. To do so, the 
operator would click the Edit Donor ID button 225 (see FIG. 
2B) in the Donor Entry/Edit dialog box 221. An Edit Donor 
ID dialog box (not shown) would preferably be made to 
appear, displaying the current donor ID. The operator could 
then enter a new ID for the donor in the New Donor ID box, 
and click an OK button (not shown) to save the ID change. 
The Donor Entry/Edit dialog box 221 reappears, showing 
the changed ID. The operator can also decide not to change 
the donor's ID, and click a Cancel option in the Edit Donor 
ID dialog box (not shown) to retain the current donor ID; in 
this case, the Donor Entry/Edit dialog box 221 would again 
reappear, showing the unchanged ID. Note that a changed ID 
is not saved in the donor record until the operator clicks the 
Apply or OK button 229 or 230 in the Donor Entry/Edit 
dialog box 221. 

[0117] At any time, the operator can search for and select 
the record for any donor who is already checked in to the 
system. However, if the donor is already checked in to the 
system, the following fields, inter alia, in the Donor Entry/ 
Edit dialog box 221 may be preferably disabled and there- 
fore cannot be modified: General tab: Gender; History tab: 
Blood Type; Status tab: Donor Status. 

[0118] Once the appropriate/desired donor data is satis- 
factorily entered, edited and/or verified using screen 221 
(FIGS. 2B-21), the donor may then be checked-in to the next 
step in the process, the Prepare Procedure step/sub-proce- 
dure (described below). Donor check-in may be accom- 
plished from any view of screen 221 by clicking the "OK" 
button 230 (or another appropriately labeled button, e.g., 
"Check-in" if so provided, not shown). This may then send 
the donor information to the Prepare Procedure portion of 
the software application (e.g., to the Prepare Procedure 
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software module, if the software is so modulized as is 
preferred). Alternatively, a pop-up dialog box (not shown) 
can be made to appear for confirmation that donor check-in 
is desired. "Yes" or "No" options may be provided in such 
a pop-up dialog box to confirm the operator's desires. 
Clicking the "Yes" option will then pass the donor infor- 
mation to the Prepare Procedure Step, as described. Note, 
clicking the "No" option will provide for not passing the 
donor information to the next procedural step; however, it 
may be made to either save all edited/entered information 
while exiting the Donor Entry/Edit screen 221, or it may be 
made to call up a further pop-up window to confirm whether 
the edited/entered information should be saved to the central 
memory 142 before exiting the Donor Entry/Edit screen 
221. Note also that, as will be described below, the donor 
data entered/edited via screen 221 may be made further 
enterable/editable at later stages of the overall procedure 
after initial check-in, still preferably through use of a screen 
221, or the like. Thus, provision (preferably through clicking 
the Select Donor icon 207 in bar 205; see FIG. 2A) may be 
made to return to screen 221 or the like at later stages of the 
procedure to enter new data or modify existing data, as may 
be desired. However, at such later stages, a check-in option 
would not preferably be made available if (as would be true 
in such a situation) the donor had/has already been checked- 
in. Thus, clicking the "OK" button 230 (see FIG. 2B, e.g.) 
would only save the information to the donor record in 
memory 142 and not proceed to a "Check-in" dialog box, if 
used (not shown). 

[0119] FIG. 3A shows the next step in the overall general 
component collection procedure which would appear after 
donor check-in is completed as described above. This next 
step corresponds generally with the shown display screen 
301 which would have been accessed via clicking on the 
Prepare Procedure icon 208 in the procedure icon area 205. 
This next step in the data entry/manipulation process shows, 
via the display screen 301, the donors who have been 
checked into the system and are now ready for selections of 
the desired collection procedures to be performed. The work 
area 202 of screen 301 in FIG. 3A then preferably displays 
a listing of donors (via a text list (not shown) or by 
representative icons as shown, or otherwise (not shown)), 
which have been checked-in according to the above-de- 
scribed procedures(s). This grouping or listing of checked-in 
donors may also be referred to as a "donor queue." A donor 
may then be selected from this queue by clicking the 
corresponding icon 302 or 303, for example. Once the donor 
is selected in screen 301 (selection being indicated by 
distinctive shading, see icon 303 in FIG3A), the next step 
can be accessed by clicking the "Prepare" button 304 in the 
main work area 202, or, in an optional embodiment, by again 
clicking the "Prepare Procedure" icon 208 in the icon area 
205. Note, a "Remove" button 305 could alternatively be 
selected to remove the donor from the Checked-in Donor 
Queue, (ie., from the work area 202) if desired. Also, help 
may be obtained at any time by selection of the "Help" 
button 306. Note, in a preferred embodiment, the donor 
icon(s) 302 and/or 303 may include the donor's photo (i.e., 
as introduced above, the computer/database system 140 may 
also be equipped with a digital camera as is known in the art 
of computer systems generally). 

[0120] There may be at least two general and perhaps 
overlapping preferences for separating the Donor Check-in 
functionality from the Prepare Procedure functionality. Spe- 
cifically, a first such preference may derive from the three 



room scenario suggested/described above, wherein a donor 
may be greeted by a receptionist or receptionist-type of 
operator in a "Reception" room or area. Then, the donor 
information described generally above (see FIGS. 2A-2I, 
e.g.) may be entered and/or edited and/or verified at such a 
"Reception" point of the overall procedure. The donor may 
then be moved to a second, discrete room where a second, 
discrete operator may perform the Procedure Preparation 
steps described hereinbelow. These rooms/areas may be 
separate physically or rather may not actually be separate at 
all, depending upon the blood center and its preferred 
operating procedures and facility arrangements. The opera- 
tors may also not be discrete; however, the second, likely 
overlapping preference for the functionality separation may 
be that there are two separate operators and the second 
operator may have different technical skills and/or qualifi- 
cations from the first operator, i.e., the second operator may 
be qualified to run the actual collection procedure while the 
first, reception operator/person may not. Thus, by separating 
these functionalities (even if the "rooms" are not separated), 
the reception person or the reception area computer may be 
given access limited only to the Select Donor icon function- 
ality, for example. At the same time, the perhaps higher 
qualified collection operator may be relieved of the data 
entry/edit tasks associated with initial check-in procedures. 

[0121] As a result of finishing the previous steps (data 
entry modification and donor check-in), the Prepare Proce- 
dure portion of the overaU process may be performed next. 
As shown in FIG. 3B, a"Prepare Procedure" sub-procedure, 
preferably a "Prepare Procedure" Wizard, as depicted by a 
first Wizard display screen 321, may substantially automati- 
cally lead the operator through the procedure preparation 
process. Note, a wizard as known in the art generally, may 
be a software module or sub-procedure which includes a 
series of screens used to accomplish a particular task or 
operation. Note, this "Prepare Procedure" wizard screen 
and/or other such screens (as follow) may be sub-windows 
or full window-sized displays. 

[0122] In particular, as shown here, respective screens 
321, 331, 341, and 351 of respective FIGS. 3B, 3C, 3D, and 
3E represent substantially sequential wizard screens 
accessed initially by the selection of the "Prepare" button 
304 (after seiectiorVhighlighting a particular donor icon, e.g. 
icon 303) of screen 321 in FIG. 3A. These wizard screens 
321-351 are then sequentially accessed, one to the next* by 
the selection of the respective "Next" buttons 322 (see lower 
portions of screens in FIGS. 3B and 3C, e.g.). Backtrack- 
ing, in reverse order, of these wizard screens is also available 
by selection of the respective "Back" buttons 323, disposed 
preferably adjacent the "Next" buttons 322. Other general 
wizard buttons such as the "Help" button(s) 324, the "His- 
tory" button(s) 325 and the "Cancel" button(s) 326 may be 
selected at any general point in this process to obtain 
respectively assistance/information, a history of data entry/ 
edits (and/or optionally displayed screen views 321-351, 
e.g.) and/or to cancel the Prepare Procedure wizard at any 
time. 

[0123] Further details of preferred process for using these 
preferred and like screens will now be set forth. 

[0124] The operator is presented with the first page of the 
"Prepare Procedure" module/wizard/ sub-procedure, the 
Donor Identification page 321 as shown in FIG. 3B. This 
page shows the donor's name, donor ID, date of birth 
(DOB), and photo (if previously taken and/or saved in the 
database 142). This page allows the operator to confirm the 
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donor's identity and, optionally, to take or update a photo of 
the donor. An "update picture" button 328 may be supplied 
for providing a new or updated photo. Field specific behav- 
ior of these items is preferably as follows: the "Donor Name 
is pre-populated with first and last name from the donor 
record data, and is preferably not editable here. The "Donor 
ID" is also pre-populated, and preferably not editable. The 
"Date of Birth" field is pre-populated using localized format, 
and not editable. And, the "Donor's photo" is also preferably 
pre-populated to further assist the operator confirm the 
proper donor is present for this procedure being prepared. If 
such a photo is not available for this particular donor, a 
generic male or female icon may be displayed. The operator 
may then click the "Next" button 322 to proceed to the next 
page of the wizard. 

[0125] A Unit Number text box 329 may also be disposed 
in either of screens 321 or 331 (or elsewhere, see FIG. 3B). 
A Unit Number is preferably a required field entry. The 
operator may enter the unit number either by typing the 
number in the Unit Number box 329, or by using a barcode 
reader (not shown, e.g., by highlighting the unit number field 
329 and then using the bar code reader to scan the supply bar 
code which would then populated this field 329). The unit 
number may be supplies related information or taken there- 
from as related to the tubing set type used, or the bag 
identifiers to be used. The Directed Donor and HLA matched 
boxes 330 are further alternative fields which could be 
entered/edited at this (or a later) stage of the procedure. 
These fields are directed to noting whether this donor is 
providing a donation for a specific pre-identified recipient, 
and the HLA match box merely records whether the HLA 
types have already been matched for such a directed dona- 
tion per pre-existing techniques. The operator may then click 
the Next button 322 to proceed to the next page, or the Back 
button 323 to return to the previous page. 

[0126] Then, as shown by the display screen 331 in FIG. 
3C, gender, height, weight, hematocrit and platelet pre-count 
parameters will preferably be entered, if not already popu- 
lated in the respective fields 332, 333, 336 and 337 as 
previously entered in and thus disposed in the database 142. 
In fact, even if these parameters are previously entered, 
these fields in this screen 331 may be made mandatorily 
re-entered here, or at least re-confirmed before the system 
140 may allow the operator or donation process to proceed 
(note, if re-entered here, it may be that this data re-entry 
could rewrite the database information at this point or at the 
end of the collection process as part of the entire record 
which is saved to the central database 142 at that time). The 
other fields shown in this FIG. 3C are preferably entered as 
well, but may be made optional. As introduced above, and 
as will be understood from further description below, the 
required fields may be populated with historical data until 
the current lab values come back. 

[0127] More particularly, the operator is presented with 
the Donor Information page 331 of the wizard, see FIG. 3C. 
Donor "vitals" are taken and entered on this page. The 
following items are preferably displayed on the Donor 
Information page 331. The Donor's Gender is preferably 
pre-populated in field 332, required, and editable via selec- 
tion: Male or Female. The Donor's Height and Weight are 
preferably also pre-populated (see fields 333) with the last 
value (from database 142, if available) in localized units, 
editable, and required. The value written to the database will 



indicate if the value was changed. The "TBV" (Total blood 
volume) in field 334 is dynamically calculated (non-edit- 
able), based on the Height, Weight, and Gender fields 332, 
333. The Donor Blood type is also preferably pre-populated 
in field 335, either from database 142 or (if unknown for this 
donor) pre-populated with Unknown. This field is preferably 
editable via a selection: O+, A+, A-B+, B-, AB+, AB-, 
or Unknown. 

[0128] The Hematocrit/Hemoglobin field 336 is labeled 
either Hematocrit as shown or Hemoglobin (not shown), 
based on the system setup that is defined by the System 
Administrator. Data in this field is required, and may be 
entered by the operator, or a default value may exist. If the 
Administrator configures this field to use a default value, and 
historical data of the configured type is available for this 
donor, the field is pre-populated with the historical data. The 
type of historical data used as the default may be configured 
by the Administrator to be one of the following types: 
Average of last three pre-procedure values; Last visit's 
pre-procedure value; No default value; Gender-based default 
value; or blood center chosen default value. The value 
written to the database and displayed on the page indicates 
if the value is one of the configurable defaults above or if it 
is a measured value entered by the operator. 

[0129] The Platelet Pre-count field 337 is also entered 
here. Data in this field 337 is required, and may be entered 
by the operator, or a default value may exist preferably as 
defined by the Administrator. If the Administrator configures 
this field to use a default value, and historical data of the 
configured type is available for this donor, the field is 
pre-populated with the historical data. The type of historical 
data which may be used as the default may be configured by 
the Administrator to be one of the following types: Average 
of last three pre-procedure values; Last visit's pre-procedure 
value; No default value; Gender or Center-wide default. The 
value written to the database and displayed on the page 
preferably indicates if the value is one of the configurable 
defaults above or if it is a measured value entered by the 
operator. 

[0130] In addition to the above, preferably-required items, 
the operator may enter the appropriate optional donor vitals 
(see generally fields 338); Temperature (an optional field in 
localized units: Fahrenheit or Centigrade); Blood pressure; 
and Pulse (optional fields). 

[0131] When all required information (and any optional 
information the operator chooses to enter) has been entered, 
the operator clicks the Next button 322 to proceed to the next 
page 341 or 351 (FIGS. 3D or 3E), or the Back button 323 
to return to the previous page 321 (FIG. 3B). Note, if a 
required field does not have an entered value, an attempted 
click of the Next button 322 will preferably present a prompt 
that a value must be entered in this field before the wizard 
can proceed to the next page. Note, if the operator enters a 
value in a field that is above or below the allowable limits 
for that field (hard limits), or a value that is unusually high 
or unusually low (soft limits), a message will preferably be 
made to appear. If this is a soft limit, the message informs 
the operator that the value is outside the limits and asks if the 
operator wishes to proceed. The operator may click a Yes 
option to use the value and proceed, or No to enter a new 
value. If this is a hard limit, the operator may be required to 
enter a new value in order to proceed. Also, if the blood 
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center uses a blood bank information system, a warning 
message will preferably be made to appear when the opera- 
tor changes a donor demographic field on the Donor Infor- 
mation page 331 (FIG. 3C). This warning would indicate 
that the demographics data must be changed in the blood 
bank information system to be permanently saved. 

[0132] In a simplified process (usually for operators with 
lower qualifications, or wanting or needing fewer choices), 
after the operator has clicked the "Next" button 322 (FIG. 
3C), the operator is then presented with the Target Procedure 
page 351 (FIG. 3E) of the wizard. Screen 341 (FIG. 3D) is 
skipped in this simplified procedure. The operator may then 
accept the recommended target procedure (shown high- 
lighted with a rightward-pointing arrow icon 355 in FIG. 
3E). Note that the target procedure is obtained by the system 
140 running the apheresis time and/or product yield opti- 
mization routines such as are run on the Trima® collection 
systems 10 (and as described below, see description accom- 
panying FIGS. 7-10) in the present system application, and 
that the parameters for the highlighted procedure are pref- 
erably shown above the procedure list. The operator may 
then optionally click the Finish button 352 (FIG. 3E) to 
complete the "Prepare Procedure" apheresis procedure 
selection process. 

[0133] Note, the running of the apheresis optimization 
routines by system 140 preferably involves the use of data 
either from storage in the central memory 142 and/or as 
input into system 140 via input devices 149 at any station 
148 (as described hereinabove) preferably through use of the 
sub-procedures described herein (i.e., using the screens 
shown in FIGS. 2A-21 and 3A-3Q and communicated 
through subsystem(s) 146 and then manipulated by the 
manipulation device 144. The manipulated data may then 
result in optimized data which can then be interpreted by the 
system as representing a system preferred target procedure 
(or procedures) such as is shown in FIG. 3E. Again, 
optimized data would provide usually either the largest yield 
in a certain time, or the shortest time to reach a minimum 
yield (see FIGS. 7-10, below). Other manipulations may 
provide for procedures which may not be either time or yield 
optimized, but which a blood center may find otherwise 
perhaps more desirable, such as platelet (or other compo- 
nent) preferences no matter what the optimization pro- 
grants) might suggest. Thus, the system 140 and manipu- 
lation device 144 can manipulate the donor statistics (vitals, 
etc.) against a large plurality of procedure types and com- 
pare with blood center prioritizations to obtain various sorts 
of procedure lists such as that shown in FIG. 3E. Preferably, 
the optimal procedure (optimized or merely manipulated 
according to system administrator preselections) may be 
returned with the rightward-pointing icon 355; however, 
preferably also other procedures will be listed also with 
various icon representations to signify prioritization. For 
example, as shown in FIG. 3E, numerous procedures are 
shown with a circle with a diagonal line which here pref- 
erably represents procedures which are not available due to 
physical (and/or safety) constraints such as the donor not 
meeting a minimum hematocrit or total blood volume pre- 
ferred therefor. Green circles, inter aha, can be used to 
signify less than optimal procedures which would neverthe- 
less be available for this donor to be subjected to. Question 
marks could be used to signify procedures which could be 



available options if the parameters (e.g., time, lab values, 
etc.) were to change (i.e., if more time were allowed for a 
collection). 

[0134] Note several alternative actions may be presented. 
For example, in some instances it may occur that more than 
one target procedure may be indicated, whereby the operator 
may then choose the preferred procedure. Or perhaps the 
donor may be disqualified such that no procedures appear 
available. The donor can be disqualified for the donation 
based on the donor vitals or screening questions. In this 
situation, the operator may press the Cancel button 326 on 
any page in the Prepare Procedure Wizard to discontinue the 
prepare procedure process. The operator may then remove 
the donor from the Checked-in Donor Queue, as described 
in the "Prepare Procedure" sub-procedure above. 

[0135] Otherwise, the donor may be unable to donate if the 
central system 140 cannot determine a valid apheresis 
procedure to run for this donor. If this is the case, the central 
system 140 preferably displays a dialog box (not shown) 
explaining the reason a procedure cannot be determined. 
Based on the blood center's policy, the operator may ask the 
donor if the donor can stay longer. The operator may then 
extend the procedure time, as described in the "Adjust 
Donation Time" alternative sub-procedure below. 

[0136] As noted, the operator may adjust the donation 
time. If the donor can only stay longer or perhaps only a 
certain limited amount of time, the operator may change the 
default maximum procedure time by clicking the Adjust 
button 353 (FIG. 3E). The operator is presented with the 
Procedure Adjustments dialog box 361 (see FIG. 3F), in 
which the operator may enter a new maximum procedure 
time. The operator may then click the OK button to return to 
the Target Procedure page 351 (FIG. 3E) of the wizard. If 
the maximum procedure time is changed, the Target Proce- 
dure page is re-optimized and possibly recommends a dif- 
ferent procedure. It is also possible that there are no proce- 
dures available as a result of the time change. 

[0137] Similarly, the operator may adjust the tubing set 
type availability. If only certain tubing sets are available, the 
operator may change the tubing set type availability by 
clicking the Adjust button 353. The operator again is pre- 
sented with the Procedure Adjustments dialog box 361, in 
which all three tubing set types (e.g. Grey, White, and Black 
options for the Trima® apheresis systems 10; other optional 
set types and/or designations may be used for other blood 
processing systems 10, as desired) are checked by default. 
The operator may uncheck one or more tubing set types. The 
operator may then click the OK button to return to the Target 
Procedure page 351 of the wizard. If the tubing set type 
availability is changed, the Target Procedure page is re- 
optimized and possibly recommends a different procedure. It 
is also possible that there are no procedures available as a 
result of the tubing set availability change. 

[0138] Note, the operator may also select certain different 
procedures in the procedure list shown in screen 351 (FIG. 
3E). The operator may select a procedure with an icon 
indicating that the procedure can be run for this donor 
(though perhaps not the optimal procedure according to the 
system 140), or a procedure with an icon indicating that the 
procedure can be run for this donor, but only if the donor's 
actual hematocrit and/or platelet precount change signifi- 
cantly from the values entered in screen 331 (or the default 
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values used in screen 331). In any event, preferably the 
operator cannot select a procedure with an icon indicating 
that the procedure cannot be run for this donor. Note that 
when the operator selects a different procedure in the list, the 
parameters for the selected procedure are shown above the 
procedure list. Note, the operator may also view any of the 
listed procedure details. To do so, the operator may double- 
click a listed procedure to view a Procedure Details dialog 
box (not shown), which may provide more detailed infor- 
mation about the procedure. The operator may double-click 
either the currently-selected procedure, or any other proce- 
dure in the list. The operator may click an OK button to close 
the Procedure Details dialog box (not shown) and return to 
the Target Procedure page 351 of the wizard. If the operator 
double-clicked a procedure other than the currently-selected 
procedure, the procedure that the operator double-clicked 
would now preferably be selected (e.g., highlighted) in the 
Target Procedure page 351. 

[0139] Note also that an operator may select different 
donation options, preferably after the step depicted by screen 
331 (FIG. 3Q, but prior to the step depicted by screen 351 
(FIG.3E). Preferably, however, this option would be limited 
to higher security users preparing the donation. Then an 
additional page 341 (FIG. 3D) would appear, allowing finer 
control of the donation. This page 341 would be presented 
only to individuals with the higher privilege level. The 
following two steps could be added for this operator. The 
operator would choose the blood product types eligible for 
this donation (e.g. platelets, RBC's or plasma). These 
choices would be used to disqualify one or more product 
types from being collected. By default, all product types are 
preferably eligible for a donation. Thus, a check in the 
corresponding box in area 342 of the "Select Products and 
Configuration" page 341 would indicate that the product 
type may be collected. If the corresponding box is 
unchecked, any procedure that would collect this product 
type is disqualified in the Target Procedure page 351 (FIG. 
3E). The three choices are platelets, plasma and red blood 
cells. Any combination hereof may be checked. As shown in 
area 343, the operator may also select alternative apheresis 
system configurations or product focus lists to utilize for this 
donor's donation. Note that these changes would preferably 
only apply to this donation. For Focus Lists, the operator 
may select a product focus list from this drop-down list. The 
center-wide default focus list is preferably pre-populated in 
this drop-down list. All focus lists that have been defined by 
the Administrator will then appear in this drop-down list. For 
Machine Configuration, the operator may select an apheresis 
system machine configuration from this drop-down list The 
center-wide default machine configuration is preferably pre- 
populated in this drop-down list. All machine configurations 
that have been defined by the Administrator will then appear 
in this drop-down list. 

[0140] At any point while using the Prepare Procedure 
Wizard, the operator may click the History button 329 (see 
FIG. 3C) to view the donor's record. When the operator 
clicks the History button 325, the Donor Entry/Edit dialog 
box 221 (see FIGS. 2B-2I) appears, showing all information 
in the donor record. To return to the Prepare Procedure 
Wizard, the operator clicks the OK button in the Donor 
Entry/Edit dialog box 221. 

[0141] Note, the sub-procedure depicted by the screens in 
FIGS. 3B-3E may be known generally as "screening" in 
suggesting that these functions may be performed in the 
second room, the "Screening" room, of the three room 
model described above. 



[0142] Then, in the next procedural step as shown by the 
display screen 401 in FIG. 4A, the donor may be assigned 
to a blood processing machine 10. Screen 401 may be 
accessed via a button such as the "Finish" button 352 
appearing on the last page 351 (FIG. 3E) of the "Prepare 
Procedure" wizard/sub-procedure, or more preferably by 
clicking the "assign machine" icon 209 appearing in the icon 
work area 205 (see FIGS. 2A and 4A, e.g.). Assigning a 
donor to a machine may be a simple matter of clicking and 
dragging the donor's icon 402 (with or without photo) to an 
available Trima® or like apheresis machine icon 404 as 
shown in the respective left and right portions 406, 408 of 
the main work area 202 in screen 401. 

[0143] Note however, that any particular donor will pref- 
erably not be available (i.e., no icon will preferably show up) 
in the icon list 406 (also labeled as a "Donor Assignment 
Queue") until completion of the "Prepare Procedure" sub- 
procedure (i.e., as accessed using the "Prepare Procedure" 
icon 208, e.g.) as described for the wizard module in FIGS. 
3B-3F. However, after the "Prepare Procedure" sub-proce- 
dure is completed, preferably after the clicking of the 
"Finish" button 352 on the last screen 351 of the wizard (see 
FIG. 3E), a donor icon for that donor, such as icon 402, e.g. 
is preferably automatically generated and automatically 
placed in the icon list 406. Thus, the donor, as represented 
by the icon, is then ready to be assigned to a particular 
apheresis assembly 10. 

[0144] In more detail, to do so, the operator will first 
preferably double-click the Assign Machine task icon 209 in 
the main window task bar 205, or, alternatively, the operator 
may select the Assign Machine element (not shown) from 
the Tasks menu 216. The Assign Machine task window 401 
is then displayed, showing two panes: the Donor Assign- 
ment Queue 406 and the Machines list 408. The Donor 
Assignment Queue 406 shows donor icons (e.g., icon 402) 
for all donors who are ready for machine assignment. Donor 
icons are preferably ordered in the queue based on the time 
an operator finished using the Prepare Procedure Wizard 
(see above) to prepare a procedure for the donor. The donor 
for whom the Prepare Procedure Wizard was finished the 
longest ago preferably appears at the top of the queue. The 
donor for whom the Prepare Procedure Wizard was finished 
most recently preferably appears at the bottom of the queue. 
The Machines list 408 shows an icon for each apheresis 
system in the facility that is enabled in the current network. 
To help the operator make a decision about which machine 
to select for a donor, the following information is preferably 
displayed as part of each machine icon: run status; time 
remaining if a procedure is currently running on the 
machine; name of the next donor queued for the machine; 
machine communications status (online or offline). 

[0145] To assign a donor to a machine, the operator 
preferably selects a donor icon from the Donor Assignment 
Queue 406 and drags it to a machine icon in the Machines 
list 408. Alternatively, the operator may select a donor icon 
402, e.g., (by highlighting/clicking it once, not shown) and 
a machine icon 404 and then click the Assign button 410 to 
make the assignment. A confirmation dialog box (not 
shown) may then be displayed with "Yes" and "No" options 
to ask the operator to confirm the assignment. If the operator 
clicks the "Yes," option, the system may then close the 
confirmation dialog box, and, in the Assign Machine task 
window 401, the following preferably occurs: the donor icon 
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402 is removed from Donor Assignment Queue 406 and the 
machine information in the Machines list 408 is updated to 
show that the donor is assigned to the machine. If the 
operator clicks the option "No," option, the system closes 
the confirmation dialog box, and, in the Assign Machine task 
window 401, the following occurs: the donor icon 402 
remains in the Donor Assignment Queue 406, and the 
machine information in the Machines list 408 is unchanged. 
After a short delay, the donor information (and photo, if 
available) appear on the apheresis system. In addition, the 
donation-specific apheresis system configuration is in effect 
on the machine. At this point, the operator may continue 
using the Assign Machine task window or select another 
option in the system main window. 

[0146] Some alternative process flows for donor/machine 
assignments are as follows. 

[0147] It may be possible that all machines 10 are non- 
functional. If this is the case, the operator (or another 
member of the facility's staff) will need to fix the problem 
at those machines 10, to make at least one machine 10 
available. If this is not possible, the operator may be required 
to remove all donors from the Donor Assignment Queue, as 
described below. 

[0148] At any time prior to machine assignment, the 
operator may edit the information about a procedure by 
selecting the donor's icon (e.g., icon 402) in the Donor 
Assignment Queue 406 in screen 401 and clicking the Edit 
button 405. The Prepare Procedure Wizard (see FIGS. 
3B-3E) appears, allowing the operator to edit the procedure 
information. Once the operator clicks Finish 352 on the last 
page 351 of the wizard, the Assign Machine task window 
401 is redisplayed. (Alternatively, the operator may redis- 
play the Assign Machine task window 401 by clicking 
Cancel 326 on any page of the wizard; however, in this case, 
the modifications that were made in the wizard are dis- 
carded.) 

[0149] At any time prior to machine assignment, the 
operator may remove a donor from the Donor Assignment 
Queue 406 by selecting the donor's icon (e.g., icon 402) in 
the Donor Assignment Queue 406 and clicking the Remove 
button 407. A Confirm Remove Donor dialog box (not 
shown) may be made to appear, allowing the operator to 
enter a reason for the removal and/or select a reason from a 
predefined list (preferably created by the Administrator). 
Once the operator clicks the OK option in the Confirm 
Remove Donor dialog box (not shown), the donor's icon is 
removed from the Donor Assignment Queue 406. 

[0150] The operator may also unassign a donor from an 
apheresis system 10 under the following conditions; namely, 
if another donor is currently donating on the machine, and 
the donor the operator wants to unassign is queued to donate 
on the machine, and/or if the machine is offline. To unassign 
the donor, the operator may click the machine icon 404 in 
the Machines list 408 and then click the Unassign button 
412. The machine icon 404 returns to its previous state. In 
addition, an icon (e.g., icon 402) for the unassigned donor 
reappears in the Donor Assignment Queue 406. To distin- 
guish this donor from donors who have not yet been 
assigned to any apheresis system 10, this donor's icon is 
gray. The donor may then be reassigned to an apheresis 
system 10 as described in the basic procedural flow, or 
removed from the Donor Assignment Queue 406 as 



described in the "Remove Donor" alternative flow, above. 
Note: the Unassign button 412 is disabled when no machine 
icon is selected. If the operator then clicks a machine icon 
(such as icon 402, inter alia) the Unassign button 412 will 
remain disabled, the unassign feature not being available for 
that machine at this time. 

[0151] If a donor is assigned to an apheresis system 10, but 
then is dismissed at the apheresis machine 10 using, for 
example, the touch-screen display 199, the machine icon 
402 in the Machines list 408 in the Assign Machine task 
window 401 returns to the "Ready for Donor" state. In 
addition, an icon (e.g., icon 402) for the dismissed donor 
reappears in the Donor Assignment Queue. To distinguish 
this donor from donors who have not yet been assigned to 
any apheresis system 10, this donor's icon is "grayed-oul". 
The donor may then be reassigned to an apheresis system 10 
as described in the general sub-procedure for Assign a 
Donor, or removed from the Donor Assignment Queue 406 
as described in the "Remove Donor" alternative sub-proce- 
dure, above. 

[0152] After assigning a donor to an apheresis machine 10 
as described, the display screen 421 shown in FIG. 4B 
appears on the corresponding display area (e.g., touch- 
screen 199, if used) of the assigned blood component 
apheresis assembly 10 itself. The operator may then either 
confirm the information appearing on the apheresis screen 
421 by depressing the "continue" button 422, or the like; or 
the operator may touch/push the box 423 marked with an 
"X" to decline the donor assignment, thus sending the donor 
data back to the central system 140 and figuratively send the 
donor back to the "waiting/screening" room. The apheresis 
screen 421 shown here may have touch-screen capabilities 
as understood in the art, or may accept input through other 
means such as mouse driven cursors, inter aha, which are 
within the skill of the art. 

[0153] Note, it is still also conceived that though perhaps 
not preferable, there may be situations in which the system 
may be configured to allow the operator to enter data directly 
on the apheresis machine 10 itself and then perform data 
manipulation and/or optimization as is known for many 
existing machines 10 without requiring the use of a central 
computer/database system 140. Nevertheless, it is also con- 
ceivable that in such a situation it may be preferable to still 
collect data at a centralized system 140 for database or 
reporting purposes. 

[0154] After the download of the information from the 
computer/database system 140 to the actual apheresis 
machine assembly 10 as described, then the computer/ 
database system 140 may preferably only be used for 
monitoring and/or reporting. This follows a preference that 
all actual apheresis control during a procedure remains 
resident in the apheresis machine 10 itself. It is possible, 
however, if not preferable, to have computer/database sys- 
tem 140 exert control over apheresis machine functions, 
including process control manipulation and optimization, 
during procedures, as well. In either case, as shown in screen 
501 of FIG. 5A, it is at this point that the computer/database 
system 140 can be used to monitor the procedure(s) occur- 
ring on one or more apheresis machines 10. All procedure 
interventions again would preferably occur directly on the 
apheresis machine 10 through its touchscreen 199 or other 
input mechanism as known in the art. 
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[0155] In monitoring mode, real time monitoring of pro- 
cedures on the centralized computer/database system 140 
allows the administrator to know the status of collection of 
any or all machines 10 at a glance. This can help with 
scheduling and management. Alarm states may also be 
displayed and/or all other occurrences and/or activities of 
each machine may be recorded (not specifically shown). As 
shown in screen 521, FIG. 5B, detailed data information can 
be called up to assess the status of a procedure. More details 
concerning these display screens and the information thereof 
will now be set forth. 

[0156] In operation the operator preferably double-clicks 
the Monitor Procedure task icon 210 in the main window 
task bar 205 (FIGS. 2A and 5A), or, alternatively, the 
operator may select the "Monitor Procedure" element (not 
shown) from the Tasks menu 216. 

[0157] The present system 140 preferably provides users 
with the ability to view the status of all procedures currently 
running on machines 10 connected on the local machine 
network 146A (see FIG. 1C), as well as procedures which 
have completed on a machine 10, but for which not all 
required finalization data has been added to. the procedure 
record. Status information is supplied continuously from 
each machine 10 to visit status table (not shown) in the 
central database 142. The Monitor Procedure module scans 
an internal visit status table recurrently; the Monitor Proce- 
dure task window 501 is preferably updated based on the 
current data in the internal visit status table. Using the 
Monitor Procedure function, operators can enter a comment 
about a procedure; enter finalization data about the proce- 
dure, such as supplies data and operator roles; view more 
detailed information about a procedure's status; or force 
record completion, inter alia. 

[0158] The basic flow for the monitoring sub-procedure is 
as follows. Two different general types of procedures are 
displayed in the Monitor Procedure task window 501; 
namely Active and Pending procedures. In Active proce- 
dures, all of the procedures currently running on machines 
10 connected to the machine network 146A, including active 
procedures currently in an alarm state, are shown. Pending 
procedures are procedures that have been completed on the 
apheresis machine 10, but for which not all required final- 
ization data may have been entered in the procedure record. 
Note, procedures are considered active from the time that 
donor and procedure data is downloaded from central sys- 
tem 140 to an apheresis machine 10, until the time that the 
central system 140 receives indication from the apheresis 
machine 10 that either the procedure run has been com- 
pleted, or the operator has indicated on the apheresis 
machine 10 that the procedure run is incomplete. 

[0159] In the Monitor Procedure task window 501, pro- 
cedures are preferably displayed in table format (as shown 
in FIG. 5A). For each procedure, the following information 
is preferably displayed: machine ID; collection stage and 
status; donor name; procedure name; and the time remain- 
ing. In addition, an icon (e.g., icon 503) next to each 
procedure description may preferably indicate if the proce- 
dure is in an active, pending, or even an alarm state. 

[0160] The operator may then optionally select a proce- 
dure in the list and then click the Add Comment button 505 
to enter a comment in the procedure record for that proce- 
dure. An Enter Procedure Comment dialog box (not shown), 



may then be made to appear. The operator can then select a 
comment from the pre-configured comment list (preferably 
created by the System Administrator) and/or enter a free- 
form text comment entry. 

[0161] The operator may then optionally select a proce- 
dure in the list and then click the Procedure Information 
button 507 to enter data about the procedure, such as 
supplies data and operator roles. A "Finalize Procedure 
Information" dialog box may then appear, showing the 
Supplies tab. (For more information about this dialog box 
(not shown), see the "Finalize Procedure" descriptions 
(FIGS. 6C-6I, below). 

[0162] The operator may also optionally select a proce- 
dure in the list and then click the Status button 509 to view 
more detailed information about the procedure. A Procedure 
Status dialog box 521 (see FIG. 5B) may then appear. 
(Optionally, the operator may double-click the selected 
procedure in the list to view this Procedure Status dialog box 
521.) This dialog box 521 preferably shows the procedure 
time (time remaining, total time, and estimated end time) 
and the current collection status for each of the three blood 
product types (platelets, plasma, and RBCs) which may be 
in the process of being collected as part of a procedure. 

[0163] Several alternative conditions and/or sub-proce- 
dures may be available in Procedure monitoring. For 
example, when an alarm, warning or alert condition occurs 
within an active separation and collection procedure, the 
system may change the icon next to the procedure descrip- 
tion in the Monitor Procedure task window 501 to an 
"alarm" icon (not shown). The operator can view the alarm 
description (preferably uploaded automatically to central 
system 140 from the apheresis system 10 generated by the 
run data for the procedure) by selecting the procedure from 
the procedure list in the Monitor Procedure task window 501 
procedures list 504, clicking the Procedure Information 
button 507, and then clicking a Procedure Log tab in the 
Finalize Procedure Information dialog box (see similar 
description in FIGS. 6C-6I, below). However, the alarm 
cannot be resolved in the preferred embodiment directly 
within the central system 140. The alarm must then be 
resolved at the machine 10. Once this alarm (and any other 
alarms on the machine) have been resolved at the machine 
10, the central system 140 may change the icon next to the 
corresponding procedure description back to an "active 
procedure" icon such as icon 502, for example, as opposed 
to an inactive icon 503. 

[0164] At any time, a procedure may no longer meet the 
active or pending criteria. An update to the visit status table 
in the central database 142 may cause a procedure that was 
previously displayed in the Monitor Procedure list on screen 
501 of procedures to be removed from the list. Only pro- 
cedures that have a status of active or pending are preferably 
displayed in the procedure list. If a procedure previously was 
active or pending, but no longer meets that criteria the next 
time central system 140 scans the visit status table, the 
procedure is no longer displayed in the Monitor Procedure 
task window 501. 

[0165] At any point in monitoring procedures using screen 
501, an operator may sort procedures in procedure list. In 
particular, the operator may click one of the column head- 
ings in the procedure list to sort the procedures using 
different criteria. Procedures may preferably be sorted by 
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one of the following: Machine ID, Status, Donor Name (first 
name, last name), Procedure, or Time Remaining. The first 
time the column heading is clicked, the procedures are 
sorted in ascending alphanumeric order. Each subsequent 
click of the column heading results in a display of the 
elements in the opposite alphanumeric order (ascending or 
descending). 

[0166] As a usual last step in the overall blood component 
separation and collection process using a central system 140, 
the record finalization and reporting function of the com- 
puter/database system 140 will now be briefly introduced. 
First, the computer/database system 140 is preferably 
capable of capturing a great deal of optional information 
from the apheresis system 10 as well as from manual entry. 
This end-of-run information may then be used in generating 
a multitude of optional reports in addition to standard run 
records, both of which optionally being formattable as 
desired by the operator (see FIGS. 6K, 6L and 6M, 
described below). Further, various types of data can be 
sorted and measured relative to each other as desired as well. 
For example, the time period of the entire collection proce- 
dure can be reported relative to the numbers and/or quanti- 
ties of the products collected (volumes or contents). Or, 
certain quality measures may be reported against either or 
any of the other data collected by the computer/database 
system 140. In addition, certain data may be manipulated, 
edited or amended, or comments added thereto after a 
collection procedure. For example, certain additional infor- 
mation may be added such as information about the type of 
tubing set used or post procedure laboratory values. Never- 
theless, the data generated by the apheresis machine 10, 
itself, very preferably would not be capable of being edited 
or changed in any way. As above, more details of the overall 
reporting functionalities will now be set forth. 

[0167] The present invention allows operators to search 
for and select any procedure record in the central database 
142, whether the procedure record is opened (as for active 
and pending procedures) or closed (as for finalized proce- 
dures). As shown, for example by screen 601 in FIG. 6A, 
operators can search for procedure records based on donor 
ID, unit number, or a range of dates. Once the desired 
procedure record has been found, the operator can access the 
procedure record to do one of the following: View and/or 
enter finalization data (see the "Finalize Procedure Record" 
sub-procedure described below); or, View and/or enter lab 
results data (see the "Lab Results Entry/Edit" description 
below; FIG. 6J) 

[0168] The Basic Flow of this sub-procedure case follows 
the scenario that the operator preferably searches by either 
donor ID or unit number, and that the operator wants to 
view/enter finalization data for the procedure. The operator 
preferably double-clicks the Select Procedure task icon 211 
in the main task bar 205 (FIGS. 2A and 6A), or, alterna- 
tively, the operator may select the "Select Procedure" ele- 
ment (not shown) from the Tasks menu 216 (FIG. 2A). The 
operator may then search the central procedure record 
database 142 for the desired procedure record(s), either by 
donor ID (see field 602) or unit number (field 603). Search- 
ing by a range of dates (see fields 604) is another preferred 
alternative. The operator clicks the desired radio button, 
which clears any information which may be currently shown 
in other selection option fields, and the operator then enters 
a full or partial entry of the donor ID or unit number or dates 



in the appropriate box. Logical and/or boolean-type searches 
are also preferably available. Alternatively, the operator may 
use the barcode reader (not shown) to enter the donor ID or 
unit number. For date searching, the operator may enter a 
starting date in the From box, and enter an ending date in the 
To box. Either date can be typed in the text box or selected 
using a pop-up calendar (see calendar 611 in FIG. 6B). 

[0169] The operator may then click the Search button 610 
or press the Enter key (on the keyboard, if used). The central 
system 140 then searches the central database 142 and 
displays all possible matching procedure records in the 
Search Results box 612. The search finds both open and 
closed procedure records. In date searching, the Search 
Results box displays all procedures that were performed 
within the specified date range. 

[0170] The operator may then click the desired procedure 
record in the Search Results box 612, and then click the 
Procedure Information button 614 (shown grayed-out in 
FIGS. 6A and 6B, since a record is not yet selected there, 
i.e., is not yet highlighted. A Finalize Procedure Information 
dialog box 621, which may also be known as a Procedure 
Data Entry Edit box 621 (see FIGS. 6C-61) then appears 
(optional double-clicking of the procedure entry in the 
Search Results box 612 may also display the Finalize 
Procedure Information dialog box 621), here showing a 
Supplies tab 631. (For more information about this dialog 
box, see the "Finalize Procedure" sub-procedure described 
below.) 

[0171] Note, alternative search steps may also be per- 
formed. For example, if the operator clicks the Search button 
610 with no search criteria given, then the Search Results 
box 612 preferably displays all procedure records in the 
central database 142. Alternatively, the correct procedure 
record may not be found, in which case the operator may 
then perform a new search by entering new search criteria. 

[0172] Also, the operator may sort procedure records in 
Search Result box 612 by clicking one of the column 
headings in the Search Results box 612. This will sort the 
procedure records using different criteria. Procedure records 
may preferably be sorted by one of the following: Unit 
Number, Date, Donor ID, or Donor Name (first name, last 
name). The first time the column heading is clicked, the 
procedure records are sorted in ascending alpha-numeric 
order. Each subsequent click of a column heading results in 
presentation of the records in the opposite alphanumeric 
order (ascending or descending). The operator may also 
view a Lab Results Entry/Edit Dialog box (see box 701; 
FIG.6J) by clicking the desired procedure record in the 
Search Results box 612, and then clicking the Lab button 
616 to view the Lab Results Entry/Edit dialog box 701 
(FIG.6J). 

[0173] The operator may preferably access the Finalize 
Procedure Information dialog box 621 for a particular pro- 
cedure using one of two methods, the Monitor Procedure 
sub-procedure described above (see FIGS. 5A-5B), and/or 
the Select Procedure sub-procedure (FIG. 6A). The operator 
can access the Finalize Procedure Information dialog box 
621 via the Select Procedure task window 601 (see FIGS. 6A 
and/or 6B), preferably if the following is true; the procedure 
will be run, is currently running, or has been run under 
control of the central system 140. Note that while using 
Select Procedure, the operator can preferably access the 
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Finalize Procedure Information dialog box 621 regardless of 
whether the procedure record is opened or closed (this is in 
contrast to Monitor Procedure; the procedure record must 
preferably be in open status in order to access it from the 
Monitor Procedure task window 501). In addition, once the 
procedure has been completed on the apheresis machine 10, 
the operator may use the Select Procedure task window 601 
to access a Lab Results Entry/Edit dialog box 701 (FIG. 6 J), 
allowing the operator to view/enter lab product results. 

[0174] Moreover, the operator can preferably access the 
Finalize Procedure Information dialog box 621 any time 
after the Prepare Procedure Wizard (see description of FIGS. 
3B-3F) has been completed for the donor/procedure. Thus, 
the operator may enter procedure information such as sup- 
plies and operator roles (see below) while the procedure is 
still running. However, even if all required data has been 
entered and saved in the procedure record, the procedure 
record is not considered closed until after the apheresis 
machine run has been completed (i.e., the central system 140 
has detected a reboot or similar such signal from the 
apheresis machine 10). In addition, in order to update the 
status of a procedure record from open to closed, all required 
information must be present in the Finalize Procedure Infor- 
mation dialog box. Required information is preferably either 
or both dictated by the central system 140 (unit number, 
machine ID, donor ID, date), and determined by the System 
Administrator during system setup (required supplies, 
operator roles, etc.). 

[0175] Once the central system 140 changes the status of 
a procedure record from open to closed, the central system 
140 preferably removes the procedure from the Monitor 
Procedure list 504 (see FIG. 5A). After this point, the 
system 140 may require use of the Select Procedure task 
window 601 to revisit the procedure record. Note: a proce- 
dure is preferably also removed from the Monitor Procedure 
list 504 if a System Administrator forces record completion 
using button 511 in FIG. 5A (i.e., when the System Admin- 
istrator determines that a record cannot or will not be 
closable in accordance with normal procedures as dictated 
herein). 

[0176] To finalize a procedure, the operator will preferably 
select a procedure listed in either the Monitor Procedure 
window 501 (FIG. 5A) or the Select Procedure task window 
601 (FIG. 6A), and then open the Finalize Procedure 
Information dialog box 621 (FIGS. 6C-6I). The procedure 
record for the selected procedure is then displayed in the 
Finalize Procedure Information dialog box 621, preferably 
in initial form with a Supplies tab 631 as shown in FIG. 6C 
by default. 

[0177] In the top portion 629 of the Finalize Procedure 
Information dialog box 621, the operator confirms all pref- 
erably required and pre -populated procedure information, as 
follows: Unit Number, Machine ID; Procedure Date; Donor 
ID; Donor Name; and End Time. All of the above informa- 
tion is preferably non-editable, and is preferably down- 
loaded from the central database 142 and/or the apheresis 
system 10 run data for this procedure. 

[0178] On the Supplies tab 631 (FIG. 6Q, the operator 
may enter procedure supplies data. The supplies data entries 
may include the following: an "X" box or column, and 
various columns which may include a Description, a Lot 
number, an Expiration date, and a Manufacturer column, 



inter alia. In the "X" box/column, preferably the left-most 
column in the grid, the Administrator preferably defines 
which supplies entries are required, using an "X" in this cell 
for such required supply information. In the Description 
field, which is preferably non-editable as defined by an 
Administrator during setup, the Administrator preferably 
sets up supplies data by providing supplies descriptions and 
defining each supply as an optional or required entry. Each 
supply description the Administrator defines preferably 
appears in the Description column in the grid. The Lot 
number is preferably required if any supplies entry is a 
required entry. This can be typed into the box, or alterna- 
tively, the operator may use the barcode reader to enter this 
data automatically. The Expiration date is also preferably 
required if any supplies entry is a required entry. This also 
can be typed into the box, or alternatively, entered using a 
barcode reader to enter this data automatically. Similarly, the 
Manufacturer data is preferably required if any supplies 
entry is a required entry. Preferably a drop-down list, edit- 
able by selection only is used for entry here. Alternatively, 
the operator may use the barcode reader to enter this data 
automatically. 

[0179] The operator may then optionally click the Opera- 
tors tab 641 (see FIG. 6D) in the Procedure Data Entry/Edit 
screen 621 (also known as the Finalize Procedure Informa- 
tion screen 621; FIGS. 6C-61) to access the operator role 
data entry area. Here, the operator may preferably enter 
information about operator roles. Each operator role entry 
may include the following: an "X" box or column; a Role 
column, and Operator ID and Name columns. The "X" box 
or column is again preferably the left-most column in the 
grid, with the Administrator having pre-defined an operator 
role entry as required such that an "X M appears in this cell 
for that role. The Role column is preferably non-editable, 
defined by the Administrator during system setup. The 
System Administrator preferably sets up operator roles data 
by providing operator role descriptions and defining each 
operator role as an optional or required entry. Each operator 
role description the Administrator defines appears in the 
Role column in the grid. The Operator ID and Name 
columns are preferably required if the operator role is a 
required entry. These may be drop-down lists, editable by 
selection only. When the operator selects an item in the 
Operator ID drop-down list, the corresponding Operator 
Name cell is preferably automatically populated with the 
operator's first and last names. Alternatively, an operator 
name can be typed in the box, but it reverts to match the 
currently-selected operator ID the next time the procedure 
record is displayed. 

[0180] The operator may then optionally click the Donor 
Information tab 651 in screen 621 (FIG. 6E) to view the 
donor information for this procedure. The donor information 
is preferably supplied from the central donor database 142 
and/or the blood bank information system, as well as infor- 
mation entered during the Prepare Procedure Wizard for this 
procedure. Once the central system 140 creates a procedure 
record for a procedure, the donor information becomes a part 
of the procedure record, providing a snapshot of this infor- 
mation on the date the procedure was run. This information 
is therefore preferably non-editable. The donor information 
preferably includes the following: Gender; Height; Weight; 
TB V (Total Blood Volume); Blood Type (if available); CM V 
and HLA status (if available); and Pre-procedure values for 
hematocrit and platelet count. In addition to the above 
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information, this tab 651 preferably also shows the post- 
procedure values for hematocrit and platelet count. This 
information is preferably provided from the apheresis sys- 
tem 10 run data for this procedure and thus, like the other 
information in this tab, these values are preferably non- 
editable. 

[0181] The operator may then also optionally click the 
Record Status tab 661 in screen 621 (FIG. 6F) to view the 
current central system procedure record status. The status 
options preferably update automatically during the proce- 
dure run and procedure record entry. The options, which are 
preferably non-editable within this module, may include the 
Procedure Record, the Machine Release, the Visit Status and 
the Reason. The Procedure Record preferably remains 
Opened until all required information has been entered in the 
procedure record; at that point, the central system may 
update this option to Closed. A check box can be used to 
indicate whether the machine has been released for the next 
donor. The Visit Status preferably shows the current status of 
the donor's visit (for example, if the procedure is currently 
running, this box shows the same status that is shown in the 
Monitor Procedure task window 501 (FIG. 5A) for this 
procedure). The Reason field may preferably be used to 
indicate whether and/or if the donor was removed from the 
Donor Assignment Queue 406 in the Assign Machine task 
window 401 (FIG. 4A) for any reason (incomplete proce- 
dure, dismissed at the apheresis system 10, etc.); the reason 
being displayed in this box. 

[0182] The operator may then optionally click the Proce- 
dure Log tab 671 (see FIG. 6G) to view the procedure name 
and the procedure log (an event log of all machine alerts, 
alarms, warnings, and operator adjustments entered through- 
out the procedure). Procedure comments that have been 
entered by a system operator may be intermixed (according 
to timestamp) with the other information in this scrollable 
region. This information is preferably variable for active 
donations and remains at the final status display for pending 
and finalized procedures. The information is preferably 
non-editable and is preferably supplied by the apheresis 
machine 10 run data and by the operator entering procedure 
comments either in this dialog box 671 or via the Monitor 
Procedure task window 501 (FIG. 5A). The operator may 
optionally click the Comment button to enter a comment in 
the procedure record for that procedure. An Enter Procedure 
Comment dialog box (not shown) may be made to appear. 
The operator can select a comment from the pre -configured 
comment list (preferably created by the Administrator) and/ 
or enter a free-form text comment entry. If the operator 
clicks the OK option, the Finalize Procedure Information 
dialog box 621, Procedure Log tab 671 is redisplayed, 
showing the date and time the comment was created, as well 
as the user ID for the user who was logged on when the 
comment was created. If the operator clicks Cancel, the 
Finalize Procedure Information dialog box 621, Procedure 
Log tab 671 is redisplayed, but the comment is not included 
in the procedure record. 

[0183] The operator may then optionally click the Run 
Summary Tab 681 (FIG. 6H) to view the machine-estimated 
product volume information. This information is preferably 
provided by the apheresis machine 10 after the run is 
complete. Until the procedure is completed, all of the fields 
in this tab are blank. The information would then be non- 
editable and defaulted from the procedure run data (machine 



run summary). This information preferably includes the 
following: the estimated volume for platelet, plasma and 
RBC products; the AC volume in platelet, plasma and RBC 
products; the estimated yield for platelet products; the total 
AC volume used; the AC administered to the donor during 
the procedure; the total blood volume processed; and Sum- 
mary remarks, preferably including one or more of the 
following: a reminder to label LRS platelet product as 
having less than lxl 0e6 white blood cells (if so leukore- 
duced, as on the Trima® system 10; a reminder to count the 
product; a reminder to verify platelet yield; a reminder to 
verify platelet volume; a reminder to determine whether 
platelet concentration is out of range; a reminder to verify 
plasma volume; and/or a reminder to verify RBC product. 

[0184] The operator may then optionally click the Blood 
Loss Tab 691 (FIG. 61) to view blood loss entries. Blood 
loss information preferably includes the Product, the Tubing 
Set Residua], the Blood Sample and an Other column. A 
check box for Rinseback Completion is also provided. In 
more detail, the Product column shows product volume for 
plasma and RBCs. This information is preferably down- 
loaded from the apheresis system 10 run data for this 
procedure, and is preferably non-editable. The information 
is determined based on the procedure that was run and the 
donor's hematocrit. Until the procedure is completed, these 
fields are blank. The Tubing Set Residual preferably shows 
the volume of plasma and RBCs remaining in the tubing set. 
This information is also preferably downloaded from the 
apheresis system run data for this procedure, and is prefer- 
ably non-editable. During the procedure, this information is 
determined based on the collection status, the tubing set 
type, the procedure that is being run, and the donor's 
hematocrit. When the procedure is completed, this informa- 
tion is determined based on all of the above, as well as 
whether or not rinseback was completed for the procedure. 
The Blood Sample column presents the volume of blood, 
entered by operator for plasma and/or RBCs, according to 
the facility's SOPs. The default value if, used, is preferably 
specified by the Administrator. The Other column includes 
any Other volume of blood (for example, estimated volume 
of a spill), entered by operator for plasma and/or RBCs, 
according to the facility's SOPs. The Donor Completed 
Rinseback check box is checked if rinseback was completed 
for the procedure. Until the procedure is completed, this box 
remains unchecked. This information is also preferably 
downloaded from the apheresis system run data for this 
procedure, and is preferably non-editable. 

[0185] After entering and/or confirming the above data 
(particularly as may be required by the SOP's of a particular 
blood center), the operator may then click the "OK" button 
622 (FIGS. 6C-6I) to save the record. The central system 
140 saves the procedure record. If all the required informa- 
tion has been entered, the central system 140 updates the 
status of the record to be closed. The central system 140 may 
then also close the Finalize Procedure Information dialog 
box 621 and redisplay either the Monitor Procedure task 
window 501 (FIG. 5A) or the Select Procedure task window 
601 (FIG. 6A), depending on the method the operator 
originally used to open the Finalize Procedure Information 
dialog box 621. 

[0186] Alternatively, the Operator may click the Apply 
button 624, at any point while the Finalize Procedure 
Information dialog box 621 is displayed to save the data in 
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the procedure record up to that point, without closing the 
dialog box 621. The central system 140 saves the procedure 
record and, if all the required information has been entered, 
the system 140 updates the record's status to closed. Simi- 
larly, at any point while the Finalize Procedure Information 
dialog box 621 is displayed, the operator may click the 
Cancel button to cancel the current entry session. The central 
system 140 may then discard all unsaved changes in the 
procedure record, and close the Finalize Procedure Infor- 
mation dialog box 621 and redisplay either the Monitor 
Procedure task window 501 or the Select Procedure task 
window 601, depending on the method the operator used to 
open the Finalize Procedure Information dialog box 621. 

[0187] Various alternative actions are also available. For 
example, the Operator may view a record for a procedure 
which has not yet begun. The central system 140 creates a 
procedure record as soon as the operator completes the 
Prepare Procedure Wizard for a procedure (see FIGS. 
3B-3E). However, the procedure does not appear in the 
Monitor Procedure task window until the donor and proce- 
dure information is downloaded to the assigned apheresis 
system 10. Prior to that time, if the operator wants to view 
the procedure record, he/she can search for the procedure 
record using the Select Procedure task window 601. The 
operator may also view and/or edit information in the 
Finalize Procedure Information dialog box 621, as described 
here; i.e., at any point in the overall process, however, in 
most instances, doing so at before a process has begun or 
during the process would be premature. 

[0188] However, Lab data entry/edit may also be per- 
formed from screen 601 (as introduced above) at any time in 
the overall process; generally after such data has been 
processed and returned from the Laboratory. Again, the Lab 
Data Entry/Edit screen 701 (FIG. 6J) is preferably accessed 
by selecting the Lab button 611 in screen 601 (FIG. 6A). 
Then, lab information may be entered/edited in screen 701 
according to the product types (see the three tabs for Platelet 
Products, Plasma Products and Red Blood Cell Products). 
Then, Lab data entry/editing may be performed according to 
the information on hand. For example, Collected Product 
information can be entered/edited (although this information 
may be downloaded from the apheresis machine 10, and thus 
may be made non-enterable/non-editable, here); Residual 
Count information can be edited/edited (as may be appli- 
cable); and Split Product information may be entered/edited 
(Split ID numbers; concentrations, bag weights, volumes 
and/or yields, e.g.), here. 

[0189] During use of the Select Procedure task window 
601, the operator may click one of the column headings in 
a grid to sort the entries using different criteria. The first time 
the column heading is clicked, the entries are sorted in 
ascending alphanumeric order. Each subsequent click of the 
column heading results in the opposite alphanumeric order 
(ascending or descending). 

[0190] Note, the Donor may be dismissed at the Machine 
10 after the central system has initiated a record. In such a 
case, the central system 140 preferably automatically closes 
the procedure record if both of the following are true: The 
donor is assigned to an apheresis system, but then is dis- 
missed using the apheresis system touch-screen display 199 
before the procedure is begun; and, the operator does not 
assign the donor to a different machine 10, but instead 



removes the donor from the Donor Assignment Queue 406 
in the Assign Machine task window 401 (See FIG. 4A). For 
more information, see the following alternative actions 
described relative to the "Assign Machine" sub-procedure 
relative to FIGS. 4A and 4B. 

[0191] The central system may also detect an Incomplete 
Run, in which case, the system 140 preferably automatically 
closes the procedure record if both of the following are true: 
the donor is disconnected from the apheresis system 10 and 
the operator indicates on the machine that the run is incom- 
plete, and the operator has completed all information nec- 
essary to finalize the procedure record. If the operator has 
not yet completed all information necessary to finalize the 
procedure record, the procedure record remains opened until 
such information has been entered, as described, above. 

[0192] Note, throughout the descriptions of preferred 
options above, there are set forth a plurality of described 
instances of data/information preferably being communi- 
cated to and from the central system 140 from and to the 
apheresis system(s) 10. Nevertheless, it is understood that 
not all of these particular types of data or information may 
be used or captured or communicated by many available 
blood processing systems. Thus, it should be understood that 
all such instances in the above description are intended as 
the preferred embodiment, and that lesser direct communi- 
cations and mere manual data transfer from and to a central 
system 140 and associated blood processing systems 10 are 
also intended within the scope of the present invention. 
Thus, for example, data may be manipulated and/or opti- 
mized on/in a central system 140, and the results of which 
may not be readily transferred to a blood processing system 
10 (see perhaps systems 10B and/or 10C as shown in FIG. 
IB, e.g.), and therefore the resulting manipulated and/or 
optimized data or information may have to be operator 
entered into such a system 10 for use thereby. Similarly, the 
results of the processing/collection procedure performed by 
a lesser compatible system (see again, perhaps systems 10B 
and/or 10C, e.g.) may not be automatically communicatable 
to the central system 140, but may be operator transferred 
(i.e., manually entered) upon procedure completion. 
Instances of preferably non-editable fields or data, as set 
forth above, would thus not be applicable here. Rather, such 
data fields would indeed be editable/enterable depending 
upon which type of blood processing system 10 were being 
used. A further similar process for data handling may be 
performed for whole blood collection systems (see e.g., the 
whole blood representation 10D in FIG. IB), wherein a data 
communicating machine is often not used (at least not in the 
initial collection process; a needle connected to a receptacle/ 
bag by a tube may be the collection device 10D). However, 
data/information may still be captured by manual data entry 
throughout the process, for example, from initial Reception 
and Screening through to Collection completion. Moreover, 
subsequent (or chair-side, or bed-side) processing may even 
be performed such as to separate the collected whole blood 
into components which may be desirably tracked in a central 
system 140. The data would rather only be manually entered, 
or perhaps even certain subsequent (or chair-side, or bed- 
side) processing machines may have data communication 
abilities so as to communicate with a central system 140. 
The quantity and/or quality of data would then only differ as 
to the type of procedure performed (e.g., whole blood 
separated into which components). 
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[0193] Lastly, if the operator desires to view and/or print 
an End-of-Run report when the procedure is complete, 
he/she may do so using the Reports feature of the Everest 
software (see generally FIGS. 6K, 6L and 6M, for 
example). Various pre-defined and/or system administrator 
defined reports are preferably generatable about donors, 
procedures and collected blood products, inter alia. The 
reports command may be an icon in the icon task bar 205 
(though not shown as such here), or may be accessible 
through the Tasks menu 216 (see FIG. 2A, e.g.), inter alia. 
A list of previously configured reports may then be made to 
appear as for example is shown in dialog box 711 of FIG. 
6K. Upon selection of a report from the list in box 711, a 
report generating dialog box such as box 721 (FIG. 6L) may 
then be made to appear. After entry of the prompted-for 
information, a report may then be generated. An example 
report is shown in the report previewer screen 731 (FIG. 
6M). The presently preferred report generator is based on 
the Oracle® Reports platform which is a readily-available 
software application (from the Oracle Corporation, Red- 
wood Shores, Calif.). Thus, data from the central may be 
transferred to such a Report generating platform to create 
reports of any desirable format in fashions known and 
understood by those skilled with Oracle® Reports or like 
software applications. 

[0194] As mentioned throughout, an important element of 
the overall system 140 is the communication subsystem 146 
which provides communication between and/or among the 
various other devices/elements. As described above, sub- 
system 146 may involve hardwire or cable connections 
between the various elements; and/or it may involve other 
devices and/or software. A further communication alterna- 
tive with the computer/database 140 may generally involve 
the internet. As is known in the art, the internet provides a 
"common language" through which multiple different sys- 
tems can communicate without requiring special tailoring of 
each system. For instance, various protocols have been 
established to facilitate data communication on what has 
become known as the internet. In particular, the TCP-IP 
(Transmission Control Protocol — Internet Protocol) is an 
internet protocol structure which was developed in a 1973 
Department of Defense research project designed to link a 
"network of lowest bidders"; now in wide commercial usage 
since about 1988. In particular, the TCP ensures that the 
information goes to its destination correctly; verifies the 
correct delivery of data from client to server; and provides 
a common way of sharing information among different types 
of systems (PC, MAC, SUN workstation, etc.). Further, the 
IP also ensures the information goes to the right location; 
moves packets of information from node to node; and 
provides unique IP addresses assigned by InterNIC (NSF, 
AT&T, & Network Solutions, inter alia.). The Internet then 
provides a web of information which can be accessed 
through a single interface (web browser). The internet can 
also provide a communication medium between a computer/ 
database system 140 and various other computer informa- 
tion systems such as those shown in FIG. IB; and ostensibly 
provide communication protocols to or with the apheresis 
machines 10 as well. 

[0195] As an example, as inventory is withdrawn or 
replenished within the hospital or blood bank, this informa- 
tion can be recorded via bar code. By connecting the 
information to the hospital information system (HIS) and on 
through to bloodaccess.com, or a like internet connection 



address, a blood donation center can then access and monitor 
local inventory levels. When one hospital needs a stat or 
immediate order for a given blood component, the blood 
center may then locate and arrange transfer of the units from 
one center or one hospital to another. The blood center can 
then replenish the units taken from the hospital within a 
short period of time (such as 24 hours) using flexible 
collection through automation. Moreover, this is not merely 
an inventory tool, it may also be tailored to fill specific needs 
such as in the "dosing" model introduced herein. 

[0196] Similarly also, donor recruitment and/or eligibility 
and/or qualification can be run by a centralized system to 
determine which donors may be able to provide certain 
products at a certain time. The data may be obtained by data 
input as above, or with data already existing in the memory 
142 and/or as may be obtained by communication with a 
discrete information system. Most preferably, these proce- 
dures could be performed without the specific potential 
donor present to predict what the donor could yield, and then 
if a desirable product is predicted (i.e., the potential donor is 
eligible or qualified to give the desired produces)), the 
potential donor could then be contacted to recruit them to 
undergo the procedure. In this fashion, a blood center could 
better tailor its blood and blood component supply to better 
match demand. 

[0197] By way of background and provision of a detailed 
application of the present invention, a description of the 
blood apheresis process and associated machinery will now 
be set forth. Various embodiments of blood component 
collection assemblies may incorporate principles of the 
present invention. However, as noted above on-line tech- 
niques have been determined to be quite effective and thus 
the present invention is being described with reference to 
such techniques. One embodiment of an on-line technique 
and attendant apparatus which may be incorporated into the 
blood component collection system 2 of FIG. 1A is illus- 
trated in FIG. 7A. An on-fine technique herein refers to the 
use of a blood processing device which is controlled by 
parameters entered directly therein and calculated or 
manipulated thereby to achieve all necessary control param- 
eters. Off-line techniques refer to the use of data entry and/or 
data manipulation performed by devices not resident on or 
within the particular blood processing device; though which 
are preferably disposed in data communication therewith. 

[0198] The blood component collection assembly 10* of 
FIG. 7A utilizes an on-fine technique in that a donor 14 
(e.g., the whole blood source) is directly integrated with the 
system 10' by fluid interconnection with the blood compo- 
nent collection device 18. This particular on-line technique 
is more particularly referred to as a dual needle configura- 
tion since there are two fluid interconnections between the 
donor 14 and the blood component collection device 18. 

[0199] The donor 14 is fluidly connected to the blood 
component collection device 18 by an inlet line 22 and 
appropriate needle assembly (not shown). Whole blood from 
the donor 14 is thus continuously provided to the blood 
component collection device 18 through the inlet line 22 for 
separation of the desired blood components) therefrom, 
utilizing an inlet pump 26 (e.g., a peristaltic pump) to 
maintain this flow if desired/required. Prior to the blood of 
the donor 14 entering the blood component collection device 
18, anticoagulant from an anticoagulant ("AC") container 30 



US 2001/0034614 Al 



25 



Oct. 25, 2001 



may be provided to the whole blood, utilizing an AC pump 
32 (e.g., a peristaltic pump) to maintain this particular flow 
if desired/required. Consequently, the inlet flow to the blood 
component collection device 18 typically includes both a 
flow of whole blood from the donor 14 and a flow of 
anticoagulant from the AC container 30. 

[0200] The blood component collection device 18 sepa- 
rates the whole blood provided on-line by the donor 14 into 
three primary constituents, namely platelets, a combination 
of red and white blood cells ("RBC/WBC"), and plasma. 
The platelets collected from the blood component device 18 
are directed through a platelet collect Iine(s) 34 to one or 
more platelet collect bags 38 via a collect pump 36. The 
plasma and RBC/WBC are provided back to the donor 14 
through a plasma line 42 and RBC/WBC line 46, respec- 
tively, both of which are interconnected with a second 
needle assembly (not shown) on the donor 14 via a donor 
return line 50. The plasma line 42 includes a plasma pump 
40 (e.g., a peristaltic pump) to maintain the flow of plasma 
if desired/required. Although plasma may be provided back 
to the donor 14 in the above manner, it may be desirable to 
collect the separated plasma in some cases. In this regard, a 
plasma collect bag 54 may be provided and interconnected 
with the plasma line 42 (interconnection shown in phantom). 
In this case, appropriate valving 56 may be incorporated in 
the plasma line 42. 

[0201] The blood component separation assembly 10" of 
FIG. 7B is similar to that of the dual needle configuration of 
FIG. 7A except that a single needle assembly (not shown) 
integrates the donor 14 within the blood component collec- 
tion assembly 10". Consequently, similar components are 
similarly identified where appropriate. With regard to the 
single needle configuration of FIG. 7B, whole blood of the 
donor 14 initially flows through a donor access line 62 and 
into an inlet line 66 which is fluidly connected with the 
blood component collection device 18 such that the platelets 
are separated and collected in the above-described manner. 
The plasma and RBC from the blood component collection 
device 18 flow through the plasma and RBC/WBC lines 42, 
46, respectively, both of which are fluidly interconnected 
with a return flow controller 74. As above, however, the 
plasma may alternatively be directed to a plasma collect bag 
54. In the event that plasma is not collected, the RBC/WBC 
and plasma are provided back to the donor 14 through the 
return flow controller 74 via a donor return line 70 which is 
interconnected with the donor access line 62. As can be 
appreciated, since only a single line is directly connected to 
the donor 14, namely the donor access line 62, blood is 
either being removed from or provided back to the donor 14 
such that the procedure is effectively two-step versus con- 
tinuous in relation to the donor 14. 

[0202] An exemplary blood component collection device 
18 which may be used in the blood component collection 
assembly 10 is more particularly illustrated in FIGS. 8A-8B. 
This and like devices 18 are the subject of various U.S. 
Patents, see particularly U.S. Pat. No. 4,387,848 to Kellogg 
et al., entitled Centrifuge Assembly, issued Jun. 14, 1983, 
and U.S. Pat. No. 4,708,712 to Mulzet, entitled Continuous- 
loop Centrifugal Separator, issued Nov. 24, 1987; inter alia, 
the disclosures of which are incorporated by reference in 
entireties herein. Such devices 18 are also commercially 



available from the assignee of the present application as 
such may be incorporated in the COBE Spectra® and/or 
Trima® apheresis systems. 

[0203] Referring to FIGS. 8A-8B, the blood component 
collection device 18 utilizes a processing channel 80 to 
provide the desired disposable extracorporeal circuit. The 
channel 80 is positioned preferably within a groove formed 
directly or indirectly in a centrifuge rotor (not shown) (e.g., 
a separate filler may receive the channel 80 and be attached 
to the centrifuge rotor), and is illustrated in the two-stage 
shape which it assumes during processing (i.e., during flow 
of blood therethrough). Although a two-stage channel 80 is 
shown and described further herein, the present invention is 
not so limited; rather, the present invention may be used also 
with single-stage and/or any other centrifugal configuration 
as well as with non-centrifugal separation machines or 
devices. 

[0204] As shown and described herein, the two-stage 
processing channel 80 generally includes a first stage 84 for 
collectively separating red blood cells ("RBC) and white 
blood cells ("WBC") from platelet-rich plasma, a second 
stage 92 for thereafter separating platelets from the platelet- 
rich plasma, a transition portion 88 defining a separation 
between the first stage 84 and second stage 92, and a control 
chamber 124 for maintaining a proper interface between the 
first stage 84 and second stage 92, namely the position of the 
interface between the RBC/WBC and platelet-rich plasma 
within the transition portion 88. 

[0205] The first stage 84 extends from one end of the 
control chamber 124 along an arcuate path generally 
inwardly, toward the axis 132 about which the processing 
channel 80 rotates via the centrifuge rotor, until terminating 
at the transition portion 88. Specifically, the end of the first 
stage 84 adjacent the control chamber 124 is positioned at a 
greater radial distance from the axis 132 than the end of the 
first stage 84 adjacent the transition portion 88. An inlet tube 
96 is fluidly connected with the first stage 84 between its two 
ends to introduce whole blood into the processing channel 
80 and a RBC/WBC tube 100 is provided in the control 
chamber 124 for removing the separated RBC/WBC from 
the channel 80. Both the inlet tube 96 and RBC/WBC tube 
100 extend externally of the rotatable device 18 for inter- 
connection with the donor 14 and/or collection bags 38, 54. 

[0206] As RBC/WBC sediment against the outer wall in 
the first stage 84 during rotation of the centrifuge rotor they 
are directed and counterflow toward the RBC/WBC tube 
100 for removal from the channel 80 due to the increased 
centrifugal forces at the RBC/WBC tube 100 in comparison 
with the transition portion 88. That is, since the first stage 84 
extends along an arcuate path generally outwardly away 
from the axis 132 proceeding from the transition portion 88 
to the control chamber 124, the centrifugal force differential 
along the first stage 84 establishes the described counterflow 
of the separated RBC/WBC. Moreover, the transition por- 
tion 88 also assists in providing for this counterflow since it 
extends along an arcuate path generally inwardly toward the 
axis 132 proceeding from the first stage 84 to the second 
stage 92. 

[0207] The platelet-rich plasma, which has a lower density 
than the RBC and WBC, flows beyond the transition portion 
88 from the first stage 84 into the second stage 92 for further 
processing, while the RBC/WBC are directed back toward 
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the RBC/WBC tube 100 in the above-described manner. The 
second stage 92 initiates at the radially inwardmost part of 
the transition portion 88 and extends along an arcuate path 
generally outwardly away from the axis 132 to a platelet 
collection chamber 104. Platelets are removed from the 
processing channel 80 at the platelet collection chamber 104 
by a platelet tube 108 which interfaces with the outer wall 
of the processing channel 80 at the platelet collection 
chamber 104. Thereafter, the second stage 92 extends along 
an arcuate path generally inwardly toward the axis 132 until 
terminating at the plasma tube 112. Both the platelet tube 
108 and plasma tube 112 extend externally of the rotatable 
device 18 for interconnection with the platelet collect bag(s) 
38 and donor 14/plasma collect bag(s) 54, respectively. 

[0208] Platelets which do not separate from the plasma in 
the initial portion of. the second stage 92 between the 
transition portion 88 and platelet collection chamber 104 are 
separated in the portion of the second stage 92 between the 
platelet collection chamber 104 and the plasma tube 112. 
These platelets will flow back towards the platelet collection 
chamber 104 in the opposite direction of the flow of platelet- 
rich plasma/platelet-poor plasma through the second stage 
92 due to the configuration of this portion of the second 
stage 92. That is, the platelet collection chamber 104 
assumes the radially outwardmost position in the second 
stage 92 such that all platelets, regardless of where separa- 
tion occurs in the second stage 92, flow towards the platelet 
collection chamber 104 for removal from the channel 80. 

[0209] Platelet-poor plasma exits the second stage 92 and 
flows out through the plasma tube 112 which interfaces with 
the inner wall of the processing channel 80 and/or continues 
to flow through the remaining portion of the processing 
channel 80 to the control chamber 124. Plasma which flows 
to the control chamber 124 exits the channel through the 
control tube 114 which joins with the RBC/WBC rube 100 
into a single outlet tube 120. The positionings and diameters 
of the RBC/WBC tube 100 and control tube 114 and the 
joinder of such into the common outlet tube 120 regulate the 
position of the RBC/WBC-platelet-rich plasma interface 
within the transition portion 88 using conservation of mass 
principles. 

[0210] As noted above, each blood component collection 
device 18 may include a prediction model appropriately 
interfaced with the operator input module 16 and/or dis- 
posed on or within the manipulation device 144 or in an 
associated memory device 142 as shown in FIGS. 1A-1D 
any and/or all of which may be used to configure the 
prediction model and/or to allow operator input of various 
parameters to be used by the prediction model for predicting 
a yield of a particular blood component to be collected 
before a collection procedure is initiated using a compilation 
of algorithms. The preferred prediction model and the opti- 
mization algorithms which are associated with the present 
invention are described in detail in U.S. Pat. Nos. 5,496,265; 
5,658,240; 5,712,798; and 5,970,423; inter alia, all of which 
being commonly assigned to the assignee of the present 
invention, the disclosures of which being incorporated 
herein in their entireties as if fully set forth here by this 
reference thereto. The algorithms and disclosures thereof 
will thus be only briefly described herein. 

[0211] The prediction model is typically configured by the 
site (e.g., the blood bank/center) for a particular blood 
processing or component collection procedure (e.g., single 
or dual needle) used by the site. Both single-needle and 
double needle procedures as shown in FIGS. 7A and 7B 



will be used in the following general description, particu- 
larly in relation to a platelet-collecting procedure (although 
of course, any collection procedure can be understood as 
being substitu table herein). In this regard, an AC infusion 
rate (i.e., the rate at which anticoagulant is provided to the 
donor 14 per the blood volume of the donor 14) and the AC 
ratio (i.e., the collective flow of AC and blood through the 
inlet line 22 in relation to the flow of AC through the line 22) 
must be specified (through configuration or modified input 
as will be discussed below). Moreover, in the event that 
plasma is to be collected into the plasma collect bag 54 in the 
collection procedure, the maximum amount of plasma which 
should be collected considering the medical and physical 
characteristics of the donor 14 must also be provided. 

[0212] And, as described in the above-mentioned patents, 
there are two alternatives for establishing the plasma volume 
limit. These will not therefore be described further here. 

[0213] Further information is required by the prediction 
model prior to performing its yield prediction function. For 
instance, the total procedure time is typically input by the 
operator or pre-configured by the site (e.g., the blood bank/ 
center). Moreover, the total procedure time may be affected 
by whether a stepdown option is utilized for the blood 
component collection device 18 so as to enhance separation 
of the various blood components. When this stepdown 
option is selected, the angular velocity of the blood com- 
ponent collection device 18 is incrementally reduced during 
the platelet-collection procedure. For instance, the stepdown 
option could provide for angular velocities for the device 18 
of 2400, 2200, and 2000 RPM, each of which would be for 
a specified duration. 

[0214] Based upon the foregoing, the configuration of the 
prediction model in relation to the blood component sepa- 
ration assembly 10' and associated protocol in effect stan- 
dardizes site protocol for purposes of "normar operations. 
However, for a particular donor 14 it may be desirable to 
alter the "configuration" for one processing run. Conse- 
quently, the prediction model may utilize a procedure in 
which certain parameters utilized in the following equations 
may be adjusted on a one-at-a-time basis. Such is referred to 
as modified input data and the associated parameters are 
procedure time, inlet flow rate to the device 18, AC ratio 
option, the desired platelet collect volume, the desired 
platelet collect concentration, and the desired source plasma 
volume to be collected. Moreover, other parameters such as 
AC infusion rate, stepdown option (yes or no), needle option 
(single or double), and high flow option (yes or no) may also 
be entered as modified input data by an operator. 

[0215] Having configured the prediction model in the 
above-described manner, the following additional informa- 
tion is provided and is utilized in the various calculations of 
exemplary Equations 1-22 presented below: (1) needle 
option, namely whether the procedure is dual needle (FIG. 
7A) or single needle (FIG. 7B); (2) run identification 
number for purposes of associating the data/output gener- 
ated by the various equations with a particular donor 14 and 
processing run; (3) the gender of the donor 14; (4) the height 
of the donor 14; (5) the weight of the donor 14; (6) the total 
blood volume as calculated in Eq. 10 below; (7) the hema- 
tocrit of the donor 14, either based upon an initial estimation 
and thereafter updated based upon analysis of the donor's 14 
blood sample (e.g., by a cell counter) or input directly from 
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such an analysis; (8) the platelet pre-count, either based 
upon an initial estimation and thereafter updated based upon 
analysis of the donor's 14 blood sample (e.g., cell counter) 
or input directly from such an analysis; and (9) whether 
plasma collection is desired in conjunction with the platelet 
collection. 

[02 16] Based upon the above initial configuration and 
subsequent data input (except when entered as modified 
input data), the following output is generated by the predic- 
tion model: (1) platelet yield; (2) inlet flow rate; (3) AC 
ratio; (4) procedure time; (5) platelet collect volume; (6) 
platelet collect concentration; (7) source plasma volume; (8) 
AC in the platelet and plasma collect bags 38, 54; (9) platelet 
post-count; (10) AC infusion rate; and (11) output approval. 
This information is utilized at least in part in the following 
equations to generate, inter alia, the predicted platelet yield 
value of the collected platelets for the case of the dual needle 
procedure of FIG. 7A and also for the case of the single 
needle procedure of FIG. 7B. The differences between those 
procedures with regard to the prediction model are identified 
herein. As will be appreciated, some of the equations are 
utilized in the calculation of the predicted platelet yield, 
whereas other equations are used to generate additional 
information for output and informational purposes. The 
variables or parameters and the units associated therewith of 
the equations are presented after the equations in the Vari- 
ables Index. 

[0217] Platelet Yield: 

Y~lxlO 6 CTj t y Q TT[l-.e X p[-E c (J nr -0.l2m (Eq. 1) 

[0218] where: 

/bp-G?in%+50)(1-1/RVV b (Eq. 2) 

[0219] and where: 

QiN-RQAd-O OOUVvPRZlSO (Eq. 3) 

[0220] Alternatively, the platelet yield may be expressed 

as: 



K-lxltPCpRVy^l-- exrt-E c (0.001/Cff-l)P%+ 
50(l-l/*)/V B -0.12j]^0 



(Eq.4) 



[0221] Platelet Collection Efficiency: 

£ C -C 1 -C 2 exp[9.91 (1-1/72)^2^^0 (Eq. 5) 

[0222] where the constant C a is defined as follows: 
[0223] d^O.803— dual needle, without stepdown 
[0224] Cj-0.840— <Jual needle, with stepdown 

[0225] where the constant C 2 is defined as follows: 

[0226] C2-4.08X10- 5 — dual needle, without step- 
down 

[0227] -dual needle, with stepdown 
[0228] and where: 

QthatQis Mp) (Eq. 6) 

[0229] In Eq. 6, t P may be provided as configuration data 
or modified data as provided above, or alternatively may be 
derived from the solution of Eq. 4 for t E . 

[0230] Effective Procedure Time: 

'e-'p ^^45=^-500(1/45-1/^), Q m >45 (Eq. 7) 

[0231] Only high-flow protocol is used for Q IN >45. 
[0232] AC Infusion Rate Constant: 

/-lOOOC^iWe) (Eq. 8) 



[0233] Alternatively to the use of Eq. 8 for the derivation 
of the AC infusion rate constant I, such may be provided as 
configuration or modified input data pursuant to the above. 

[0234] AC Ratio: 

[0235] Initially, the AC ratio may be provided as configu- 
ration or modified input data pursuant to the above. In 
configuration, it is defined as follows: 

R=l+2.51///low=l. 33(1 +2.51///) medium=1.67(l+ 

2.51//*) high Eq.9) 

[0236] Total Blood Volume: 

Vb=604+0.006012 A 3 +14.6 TV ml (male)=183+ 
K 0.005835 1 3 +15.0 W ml (female) (Eq. 10) 

[0237] Plasma Collect Factor: 

[0238] AC infusion rate control maintains the AC flow to 
the donor as: 

0acd=O-OO1 / V B (Eq. 11) 

[0239] where the inlet flow associated with this is: 

Gino=*0acd=O-OO1 IRV B (Eq. 12) 

[0240] Q IN is proportional to the total AC flow, as given by 
Eq. 3, which includes the AC that flows to the platelet collect 
bag 38 and the plasma collect bag 54. P (Eq. 13) is the factor 
by which is increased by collecting AC, relative to not 
collecting AC. That is, 



J'-GiN^iNo-OK'erage 0 ac )/{?acd 
[0241] where: 

^♦(/acp^cd) [Vcfih-lSO/QrJ+VstJih-SOO/ 
Qudl 

[0242] and where: 

[0243] Platelet Collect Volume: 

Vc-lxl0^r/[C B (l+;f AC p)] 
[0244] Source Plasma Volume: 
[0245] The four choices provided are as follows: 



(Eq. 13) 



(Eq. 14) 



(Eq. 15) 



(Eq. 16) 



V SP =0 

= Vcon-Vc 
= /spVb-Vc 

= specified as modified input 



(Eq.I7) 



2:0 



(Eq.18) 



(Eq. 19) 



[0246] where: 

[0247] and where: 

o.ois/ sp so.i5 
[0248] Donor Post-count: 

^po-Cp R exp[-£: c (0.001/(/?-l)W E +50(l-l//?)/V B - 

0.12)]i§C PR (Eq.20) 

[0249] A warning is given if Cpo<100. 
[0250] Collect \biumes: 

WM1+/acp) (Eq. 21) 

Vsre-Vspd +jf AC p) (Eq. 22) 

[0251] The primary equation to be solved for purposes of 
the yield prediction by the prediction model is Eq. 4. 
Consequently, Eqs. 1-3 and 5-22 are ancillary to Eq. 4 
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although they may be used to calculate other output data 
and/or information required by Eq. 4. With regard to the 
manner in which Eqs. 1-22 are solved, all the iteration loops 
arc preferably based on the technique of successive approxi- 
mation, in which each iteration is a repeat of the previous 
one, but using updated parameter values calculated in the 
previous iteration. This process continues until all the con- 
vergence criteria are met. The convergence criteria are that, 
on successive iterations, the variable difference is ^1 for 
V c ,^0.2 for t E , and ^10 for C B . 

[0252] As noted above, the foregoing was based upon a 
dual needle configuration as illustrated in FIG. 7A. In the 
event that a single needle configuration such as that illus- 
trated in FIG. 7B is utilized, the following Eq. 7 is used in 
place of Eq. 7 and the constants Q and for Eq. 5 are as 
follows: 

C>0.803 

~'e-'p> ^20»/ p -215(l/20-l/e iN ), <?d*>20 (eq. 7) 

Variables Index 
[0253] Symbols for Equations: 

[0254] C lf (^constants in platelet collection efficiency 
equations 

[0255] C B «=platelet concentration in collect bag, 
expressed as 10 3 platelets/microliter 

[0256] Cpo-donor post-count, expressed as 10 3 
platelets/microliter 

[0257] CPR=donor pre-count, expressed as 103 
platelets/microliter 

[0258] EOplatelet collection efficiency 

[0259] £ACP=AC expressed as a fraction of pure 
plasma volume 

[0260] fBP=fraction of VB processed in platelet col- 
lection procedure 

[0261] fSP»VCON expressed as a fraction of VB 

[0262] FY=user-specific (e.g., blood bank/center) 
yield calibration factor 

[0263] H«hematocril of donor or patient 

[0264] I=AC infusion rate constant 

[0265] L=donor or patient height, inches 

[0266] P«plasma collect factor 

[0267] QAOAC flow, ml/min 

[0268] QACD=AC flow infused into donor for plate- 
let collection procedures, ml/min 

[0269] QIN«inlet flow, ml/min 

[0270] QINA-average inlet flow for platelet proce- 
dures, ml/min 

[0271] QINO=RQACD=inlet flow associated with 
QACD, ml/min 

[0272] AC=ratio 

[0273] tE=equivalent procedure time, min 



[0274] tP=procedure time, min 

[0275] VB«total blood volume of donor or patient, 
ml 

[0276] V«volume of pure plasma in platelet collect 
bag, ml 

[0277] VCB«=total volume in platelet collect bag, ml 

[0278] VCON=volume constraint for total pure 
plasma collected, ml 

[0279] VCONH=higher value of VCON, ml 

[0280] VCONL=lower value of VCON, ml 

[0281 ] VSP^volume of pure plasma in source plasm a 
bag, ml 

[0282] VSPB^total volume in source plasma bag, ml 

[0283] W«=donor or patient weight, lbs 

[0284] WOweight constraint associated with 
VCON, lb 

[0285] Y=plalelet yield, number of platelets. 

[0286] As noted above, the computer/database assembly 
140 associated with principles of the present invention 
interfaces with or at least provides information to one or 
more blood component collection assemblies 10 to provide 
a blood component collection system 2. That is, although 
there are definite advantages to having an interface between 
the computer/database assembly 140, and the blood com- 
ponent collection device 18, the optimization procedure may 
be performed at any location and input into the blood 
component collection device 18 in any manner. Since the 
general principles of the blood component collection assem- 
bly 10 were described with relation to the collection assem- 
blies 10', 10" (FIGS. 7A and 7B) which included the blood 
component collection device 18 and its various features, the 
computer/database assembly 140 will be described in rela- 
tion to such assemblies 10 1 , 10". However, it will be appre- 
ciated that the fundamental optimization principles of the 
present invention are not limited to these collection proce- 
dures and/or apparatus. 

[0287] As noted (FIGS. 1A-1D), the computer/database 
assembly 140 generally includes a central station 148, as 
well as a manipulation device 144 and a memory device 142 
(not separately shown). Initially, it should be noted that the 
manipulation device 144 is preferably separate from the 
internal control of the blood component collection device 
18. Device 18 also preferably remains accessible by the 
operator interface device 16 (which could include the touch 
screen introduced above). However, typically the manipu- 
lation device 144 will be integrated with (e.g., put in data 
communication relationship with) this internal control 
device 16. The central memory device may also be separate 
from the central manipulation device 144 (as well as from 
the individual blood processing machines 10 and/or their 
control elements 16). The memory device need only be put 
in data communication relationship with the data manipu- 
lation device 144 and/or one or more control elements of the 
central computational/database assembly 140 and/or one or 
more blood processing machines 10. 

[0288] Referring now to FIG. 9A, the computational/ 
database assembly 140 will be described with regard to a 
standard exemplary procedure. The central input station 148 
will typically be used by blood banks/centers as the primary 
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means for donor data input and donor data management. As 
introduced above in the relation to FIGS. 2A-2E, informa- 
tion relating to a donor such as gender, height, weight, total 
blood volume, blood type, temperature, pressure and demo- 
graphics will preferably be input at the central input station 
148, or could be easily downloaded to the computer/data- 
base assembly 140 from a disparate system such as systems 
3 and/or 4 as shown in FIG. IB. Moreover, information 
relating to the donor's hematocrit and a blood component 
pre-count (such as platelet pre-count), both of which may be 
obtained from a donor blood sample and determined by 
known techniques such as cell counters, may also be entered 
at the central station 148. In addition to donor-related data, 
the particular type of collection procedure to be used for the 
donor (e.g. single needle or double needle) may be input/ 
confirmed at the central input station 148. These also could 
be downloaded from a disparate system. Based upon this 
information and certain site-standardized conditions (e.g., 
total procedure time, collection efficiency, AC infusion rate), 
an initial procedure order is thereafter generated preferably 
by the manipulation device 140 which specifies the various 
process control parameters associated with the selected 
collection procedure. 

[0289] The initial procedure order may be transferred/ 
down-loaded onto the internal control of a blood component 
collection device 18 by a computer network system (FIGS. 
1A and IB) or by other methods such s floppy disk transfer 
(not shown). The operator interface module 16 may be used 
to assist this process if required/desired. When this operator 
interface module 16 exists, it may of course still be used as 
an alternative for the initial donor data input and/or to 
generate the initial procedure order including optimization 
and thereby alleviate the need for a central input station 148. 
However, it is believed that it will be more efficient to use 
the central input station 148 and the associated central data 
manipulation device 140, preferably in conjunction with the 
central memory database. Although this initial procedure 
order may be used in the collection process, the initial 
procedure order may also be optimized in accordance with 
principles of the present invention to obtain one or more 
optimal values for the process control parameters. This 
optimization may also be performed on the individual blood 
processing machines 18, but is preferably conducted on/by 
the central data manipulation device 140. As noted, this 
optimization process may be utilized before the collection 
procedure is actually initiated, but may also be initiated 
during a given collection procedure and such is referred to 
as downstream optimization although if performed after 
initiation, and though possibly performed at the central 
computer/database 140 on by manipulation device 140, it is 
preferred that post-initiation changes be effected only at or 
by the individual machines 10. 

[0290] With regard to the various optimization options, 
process control parameters may be derived for a product- 
based optimization. More particularly, the computer/data- 
base assembly 140 and specifically the manipulation device 
144 derives process control parameters for achieving a 
predetermined yield of blood components through a maxi- 
mization of at least one process parameter as will be 
discussed below in relation to the optimization models 152 
(FIG. 9B), and 172 (FIG. 9Q, for example, as noted above, 
in the United States a single platelet product (SPP) is 3x10" 
platelets and a double platelet product (DPP) is 6x10" 
platelets. Consequently, the manipulation device 144 may be 



configured to provide a number of product-based optimiza- 
tions such as SPP and DPR Although the exact values for a 
current U.S. SPP and DPP could be configured into the 
manipulation device 144, in order to increase the probability 
that the actual yield will equal or exceed the yield require- 
ments for a current U.S. SPP or a DPP, the site may configure 
a SPP to be 35x1011 platelets and a DPP to be 7.0x101 
platelets (e.g., to effectively provide a given confidence level 
over the minimum that the specified yield will actually be 
met). 

[0291] The manipulation device 144 may also be config- 
ured to provide a time-based optimization. That is, for a 
given amount of time which a donor is available, the 
manipulation device 144 will derive those process param- 
eters which allow for the collection of a "maximum" amount 
of platelets in this time period in relation to a maximization 
of al least one of the process control parameters. 

[0292] Once the optimization is complete, the values for 
the various process control parameters generated thereby, as 
well any ancillary/previously specified values, are down- 
loaded to the internal control of the blood collection device 
18 such that the collection procedure may be initiated or 
reinitiated (downstream optimization) as the case may be in 
accordance with these values. Once the procedure is com- 
pleted, certain data is transferable (electronically through the 
communication subsystem 146 or otherwise as noted, e.g., 
floppy disk) back to the manipulation device 144 and/or the 
central memory/database and/or the central input station 148 
for further use with regard to the particular donor. In 
addition, this information as well as the initial input may be 
used to generate various types of reports which may further 
assist in the management of the blood bank/center (e.g., 
individual run, donor/patient, summary reports, etc.). That 
is, this information may be used in the derivation of subse- 
quent procedure orders for the particular donor or even for 
improved efficiency for entire pool of donors. For instance, 
in the event that a certain AC infusion rate was used in the 
collection procedure which had certain effects on this par- 
ticular donor, this may be recorded in the central memory/ 
database 142 such that a lower AC infusion rate would be 
suggested/required for subsequent donations by this donor 
and perhaps also for the entire pool. 

[0293] One model which may be incorporated into the 
manipulation device 144 is illustrated in FIG. 9B and will 
be described with regard to platelet collections in accor- 
dance with the dual needle configuration of FIG. 7A, 
although the device 144 may be used with a variety of other 
collection procedures and including the single needle con- 
figuration of FIG. 7B, as well as with various other blood 
components. Initially, it should be noted that all references 
in FIG. 9B to "derivations" are actually provided by the 
prediction model discussed above such that there is either an 
appropriate communication interface between the prediction 
model and manipulation device 144 or the manipulation 
device 144 actually includes the prediction model disposed 
thereon or therein. Moreover, as noted the prediction model 
described here is specific to the blood component collection 
machine 18 and to platelet collections. Therefore, if other 
machines are used, the associated prediction model would 
also likely change as noted. Moreover, the associated pre- 
diction model may also vary in the case where different 
blood components such as red blood cells are to be collected. 
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[0294] The optimizer model 152 of FIG. 9B may be used 
for both product-based and time-based optimizations. Ini- 
tially, the optimizer model 152 will be described with regard 
to a product-based optimization. That is, the fundamental 
premise of the optimization is to achieve a predetermined 
platelet (or other blood component type) yield (or within a 
yield range), preferably in the minimum amount of time. 

[0295] The optimizer model 152 of FIG. 9B is comprised 
of four iterative loops. Generally, the first loop 156 is a 
derivation of an inlet flow (Q IN ) associated with a specified 
AC infusion rate (I S pec) which is typically set at a maximum 
value for purposes of the present invention and which is 
entered at the input station 154. This derivation is thereafter 
performed by the processing station 158 and includes the 
solution of Eqs. 4, 8, 14, and 16 and/or equations ancillary 
thereto by the prediction model as discussed above. 

[0296] There are of course various convergence criterion/ 
criteria which may be incorporated into the first loop 156. 
For instance, convergence may be based upon the current 
inlet flow (Q^c) in the first loop 156 through use of a 
binary search technique. In this case, in solving the noted 
equations at the processing station 158 certain parameters 
remain fixed in the iterative derivation of the inlet flow (Q^) 
which achieves the specified AC infusion rate (I SPEC ) and 
these parameters are also specified at input station 154. 
These include the total blood volume (V B ) which can be 
calculated using Eq. 10 since the donor's height, weight, and 
gender are entered at the central input station 148, and the 
AC ratio (R), which can be calculated using Eq. 9 since the 
donor's hematocrit (H) has been determined, or may be 
specified at some value. Moreover, the total procedure time 
(t P ) remains fixed in each iterative derivation of the inlet 
flow (0i N ) associated with the specified AC infusion rate 
Ospec) i° the firs* loop 156. However, since the total 
procedure time (t P ) is not known in the case of a product- 
based optimization and thus cannot be specified at the input 
station 154, a current total procedure time (t P _c) initially will 
be assumed (e.g., this assumption is configured in the 
optimizer model 152 and since a range of total procedure 
times is provided in the prediction model 20 as noted above, 
the mean total procedure time (t p ) is typically configured 
into this portion of the optimizer model 152 as the initial 
current total procedure time (t P ^)). The "current" designa- 
tion is used for the total procedure time in this case since the 
optimizer model 152 provides for an adjustment of the total 
procedure time after each iterative determination of the inlet 
flow (Q, N ) which provides the specified AC infusion rate 
Ospec) toe second loop 160 in order to achieve the desired 
yield (Y) if required in the case of a product-based optimi- 
zation as will be discussed in more detail below 

[0297] Generally, the inlet flow-based binary search tech- 
nique convergence may be provided by assuming a current 
value for the inlet flow (Q^^), calculating a current plasma 
collect factor (P^) using the current total procedure time 
(t P -c)> calculating a current AC infusion rate (l c ) using the 
current inlet flow (Q IN . C ) and current plasma collect factor 
(Pc), and adjusting the current inlet flow (Q IN J (at the 
parameter update in the first loop 156) in accordance with 
the selected binary search technique until there is a prede- 
termined convergence between the two most recent values 
for the current inlet flow (Q w . c ) (i.e., wherein the difference 
between the two most recent values of Q IN . C is less than 
some predetermined amount which means that the conver- 



gence criterion is met). In the case of a binary search 
technique, there will always be convergence (i.e., the con- 
vergence criterion will always be met) such that the opti- 
mizer model 152 will always exit the first loop 156 and enter 
the second loop 160. 

[0298] As an alternative to the noted inlet flow-based 
convergence criterion/criteria and the noted binary search 
technique, another possibility is to base convergence on the 
specified AC infusion rate (Ispec) and us e an iterative 
derivation to determine the desired inlet flow (Q IN ). In this 
case, the first loop 156 is used to once again iteratively 
derive the inlet flow (Q^) which provides the specified AC 
infusion rate (I SPEC ) at the processing station 158 from 
certain specified parameters. That is, the first loop 156 is still 
a maximization of the inlet flow (Q IN ) based upon the 
specified AC infusion rate (I S pec) which should be associ- 
ated with the donor 14. This is again primarily through the 
solution of Eqs. 4, 8, 14, and 16 and/or equations ancillary 
thereto by the prediction model discussed above. 

[0299] For purposes of solving the above-identified equa- 
tions in relation to the infusion rate-based convergence 
criterion, certain parameters remain fixed in the iterative 
derivation of the inlet flow (Q^) which achieves the speci- 
fied AC infusion rate (I SPEC ) in the first loop 156 and these 
parameters are also specified at the input station 154. These 
include the specified AC infusion rate (I SPEC ) which is 
known and which is typically a maximum value for the 
donor 14, the total blood volume (Vg) which can be calcu- 
lated using Eq. 10 since the donor's 14 height, weight, and 
gender are entered in the central input station 148 or 
downloaded from a disparate information database, and the 
AC ratio (R) which can be calculated using Eq. 9 since the 
donor's 14 hematocrit (H) has been determined and input in 
the central input station 148 or otherwise downloaded, or 
may be entered as modified input data. Moreover, the total 
procedure time (t P ) remains fixed in each iterative derivation 
of the inlet flow (Q IN ) associated with the specified AC 
infusion rate (I SPEC )- However, once again the total proce- 
dure time (t P ) is not known in the case of a product-based 
optimization and thus cannot be specified at the input station 
154. Therefore, a current total procedure time (tp.^ initially 
will be assumed (e.g., this assumption is configured in the 
optimizer model 152, and since a range of total procedure 
times is provided in the prediction model as noted above, the 
mean total procedure time (t P ) is typically configured into 
the first loop 156 of the optimizer model 152). The "current" 
designation for the total procedure time is used for the 
above-identified reasons relating to the adjustment of the 
total procedure time in the second loop 160 if required to 
attain the desired yield (Y). 

[0300] The solution of Eqs. 4, 8, 14, and 16 also requires 
that certain values be assumed for certain of the remaining 
parameters with still other parameters being derived from 
this assumption. In this case, an iterative procedure is used 
and updated/current values are used in the next iterative 
calculation^). All parameters which change on each itera- 
tion of the first loop 156 are identified herein with a "c" 
subscript to designate that the most current value is to be 
used. Although the derivation of that inlet flow (QIN) which 
provides the specified AC infusion rate (I S p E c) mav be 
accomplished in a variety of manners via Eqs. 4, 8, 14, and 
16, one way is to assume a current value for the plasma 
collect factor (Pc), then calculate the current inlet flow 
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(CWc) using the specified AC infusion rate (I S pec)» then 
calculate the current yield (Y^) f then calculate the current 
plasma collection factor (P c ) using the current yield (Y c ), 
and repeat this procedure with the current values until there 
has been acceptable convergence on the current inlet flow 
(Qin-c) m relation to the specified AC infusion rate (I SPEC ) 
(e.g., when the particular convergence criterion/criteria is 
met/established). When there is acceptable infusion rate- 
based convergence, the optimizer model 152 exits the first 
loop 156 and enters the second loop 160. In order to offer 
protection for cases when there is no such convergence, a 
maximum number of iterations for the first loop 156 may be 
specified (not shown). 

[0301] The second loop 160 of the optimizer model 152 is 
a total procedure time (t P ) iteration. That is, the second loop 
160 is an iterative adjustment of the current total procedure 
time (t P _c). Initially, in the second loop 160 and in the case 
of a product-based optimization the model 152 will never 
exit at the first comparator 162 since a total procedure time 
(t P ) is not specified at the input station 154. Consequently, 
the optimizer model 152 proceeds to the second comparator 
166 where convergence criteria (i.e., more than one check) 
is made. One convergence criterion which is checked at the 
second comparator 166 is whether the current yield (Y^ is 
greater than or equal to the desired and specified yield (Y). 
in this case, the current yield (Yq) may be calculated based 
upon the values specified at the input station 158, values 
derived at the processing station 158, and the current total 
procedure time (t P ^) for comparison with the desired and 
specified yield (Y) (in some cases, this current yield calcu- 
lation (Y c ) may have been performed in the first loop 156 
and need not be repeated in the second loop 160). If the yield 
convergence criterion is met, the model 152 exits the second 
loop 160 and actually exits all the way through to the exit 
151, as will be discussed below. In this case, the specified/ 
derived values are "optimal" and the collection procedure 
could be performed on the device 18 using the noted values 
for the various control parameters. 

[0302] In the event that the yield-based criterion is not met 
at second comparator 166, the second comparator 166 looks 
to a total procedure time-based convergence criterion which 
may be similar to that discussed above with regard to the 
inlet flow-based criterion (e.g., using a binary search tech- 
nique with the convergence criterion then being a predeter- 
mined difference between the two most current values of the 
total procedure time (t P . c )). On the first time through the 
second loop 160 after the noted yield-based convergence 
criterion has failed and the total procedure time convergence 
criterion has failed, the current total procedure time (tp.c) is 
adjusted and the model 152 returns to the first loop 156. That 
is, each time that the current total procedure time (t P ^) is 
adjusted in the second loop 160, the entirety of the first loop 
152 is repeated (i.e., a new inlet flow (Qj N ) associated with 
the specified AC infusion rate (Isp EC ) is derived using the 
current total procedure time (tp.c) provided by the adjust- 
ment in the second loop 160). Other convergence criterion/ 
criteria could be used in the second loop 160, such as 
specifying a maximum number of iterations to be performed 
by the second loop 160. 

[0303] In the event that the yield-based convergence cri- 
terion is not met on the second loop 160 and the total 
procedure time-based convergence criterion is met at the 
second comparator 166 in the second loop 160, the optimizer 



model 152 exits the second loop 160 and enters the third 
loop 164. The third loop 164 is an iterative adjustment of the 
AC ratio (R). However, the model 152 initially enters the 
third comparator 169 where convergence criteria (i.e., more 
than one) are checked. One convergence criterion is again 
the above-noted yield-based convergence criterion. If this 
yield-based convergence criterion is again not met, an AC 
ratio-based convergence criterion is checked at the third 
comparator 169. This may be similar to the inlet flow-based 
criterion discussed above (e.g., using a binary search tech- 
nique with the convergence criterion being the two most 
current values of the AC ratio). On the first time through the 
third loop 164 after the yield-based criterion has failed and 
the AC ratio-based convergence criterion has failed, the AC 
ratio is adjusted and the optimizer model 152 returns to the 
first loop 152. That is, each time that the AC ratio (R) is 
adjusted in the third loop 164, the entirety of the first and 
second loops 156, 160, respectively, is repeated. Other 
convergence criterion/criteria could be used in the third loop 
164, such as specifying a maximum number of iterations of 
the third loop 164. 

[0304] In the event that the yield-based convergence cri- 
terion is not met in the second or third loops 160, 164, 
respectively, and the second and third comparator 166, 169, 
respectively, and the AC ratio-based convergence criterion is 
met at the third comparator 169 in the third loop 164, the 
optimizer model 152 exits the third loop 164 and enters the 
fourth loop 168. The fourth loop 168 is an iterative adjust- 
ment of the specified AC infusion rate (I SPEC ). However, the 
optimizer model 152 initially enters the fourth comparator 
170 where convergence criteria (i.e., more than one) are 
checked. One convergence criterion is the noted yield-based 
convergence criterion. If the noted yield-based convergence 
criterion is not met at the fourth comparator 170, an AC 
infusion rate-based criterion is checked at the fourth com- 
parator 170. This may be similar to the inlet-flow based 
criterion discussed above (e.g., using a binary search tech- 
nique with the convergence criterion being the two most 
current values of the AC infusion rate). On the first time 
through the fourth loop 168 after the yield-based criterion 
has failed and the AC infusion rate-based convergence 
criterion has failed, the AC infusion rate is adjusted and the 
model 152 returns to the first loop 152. That is, each time 
that the specified AC infusion rate (I SPE c) k adjusted, the 
entirety of the first, second and third loops 156, 160, 164, 
respectively, is repeated (with the AC ratio set back to its 
initial value as entered at the input station 154 on each 
iteration of the fourth loop 168). Other convergence crite- 
rion/criteria could be used in the fourth loop 168, such as 
specifying a maximum number of iterations of the fourth 
loop 168. In cases where the specified AC infusion rate 
(Wec) ^ actually the maximum AC infusion rate, typically 
the fourth loop 168 will execute only a single time with a 
one-time increase in the AC infusion rate of, for instance, 
20% (e.g., may be site-configured). 

[0305] In the foregoing loops where a yield-based con- 
vergence criteria are identified, when the criteria are met the 
optimizer model 152 exits to exit 151 and the specified/ 
derived (i.e., current) values for. the various process control 
parameters may be provided to the device 18 for performing 
the collection procedure. However, there may be cases 
where no optimization occurs, such as when the optimizer 
model 152 exits to the exit 151 based upon the AC infusion 
rate based convergence criterion being met. 
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[0306] The optimizer model 152 may also be used for a 
time optimization. That is, the optimizer model will derive 
optimal process parameters for a predetermined total pro- 
cedure time (t P ) through maximization of at least one of the 
process parameters in order to maximize the platelet collec- 
tion (or for other blood component types). In this case, the 
optimizer model 152 only executes the first loop 156 to 
derive the inlet flow (Q^) associated with a specified AC 
infusion rate (I SPEC ) (typically a maximum value) using the 
input total procedure time (t P ) in this iterative derivation 
instead of the assumed total procedure time (t p ) referenced 
above. Once there is acceptable convergence as defined 
above in the product -based optimization such that model 
152 exits the first loop 156, the current yield (Y^) may be 
calculated in the first loop 156 (but again may already have 
been calculated in the first loop 156 at the processing station 
158 such that no further calculation is required) and the 
convergence criterion will be met at the first comparator 162 
when entering the second loop 160 (i.e., in a time-based 
optimization when a total procedure time is specified at the 
input station 154, the model 152 will exit when entering the 
second loop 158). As a result, the inlet flow (Q IN ) and AC 
infusion rate (I) will be optimal and the collection procedure 
may be performed with such values. 

[0307] Another optimization model is presented in FIG. 
9C and may be used for both product-based and time-based 
optimizations. As in the case of the optimizer model 152, the 
optimizer model 172 may interface with the prediction 
model or actually integrally incorporate the prediction 
model, and thus reference to Eqs. 1-22 will be further made 
herein. Generally, the optimizer model 172 is based upon the 
principle that optimization occurs when an optimal inlet 
flow (Ql) associated with an optimum system collection 
efficiency is used in the derivation of various process control 
parameters. Referring to FIG. 10, a representative inlet flow 
(QwVyirid 00 curve is presented to show the optimal inlet 
flow (Ql) associated with the maximum yield (Ymax)* This 
optimal inlet flow (Qj) is mathematically expressed by Eq. 
23 presented below which results from differentiating Eq. 4 
of the prediction model with regard to the inlet flow (Q IN ). 
As can be appreciated, where different algorithms are used 
in the associated prediction model (whether based upon 
collection of blood components other than platelets, differ- 
ent collection apparatus, or alternative derivations of the 
various parameters with the same collection procedure and 
apparatus), the optimal inlet flow may be mathematically 
expressed in a different manner. 



q l = (il je-wie-vw . c 3 (Eq. 23) 

_ 1 Qo * 45 for Dual NeedleCDAT) ^ 2 4) 
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[0308] Based upon the foregoing, the optimal inlet flow 
(OjJ is really "optimal" in terms of the collection apparatus. 



[0309] Referring again to FIG. 9C, the optimizer model 
172 will initially be described with regard to a product-based 
optimization wherein the desired yield (Y) is specified at 
input station 184. Generally, the inlet flow (Q IN ) associated 
with a specified AC infusion rate (i SPEC ) (typically the 
maximum AC infusion rate and also specified at input 
station 184) is iteratively derived from certain other speci- 
fied parameters. This inlet flow calculation, particularly 
when the maximum AC infusion rate Omax) and maximum 
AC ratio (Rmax) are specified, the inlet flow (Q^is optimal 
based on the physiological considerations of the donor 14. 
This is primarily through the solution of Eqs. 4, 8, 14, and 
16 and/or equations ancillary thereto by the prediction 
model discussed above. For purposes of solving these equa- 
tions certain parameters remain fixed in the iterative deri- 
vation of the inlet flow (Q w ) which achieves the specified 
AC infusion rate (I SPEC ) and these parameters are also 
specified at input station 184. These include the total blood 
volume (Vg) which can be calculated using Eq. 10 since the 
donor's height, weight, and gender are entered in the central 
input station 148, and the AC ratio (R), which can be 
calculated using Eq. 9 since the donor's hematocrit (H) has 
been determined, or may be specified at some maximum 
value. Moreover, the total procedure time (t P ) remains fixed 
in each iterative derivation of the inlet flow (Q IN ) associated 
with the specified AC infusion rate (I SPEC ). However, since 
the total procedure time (t P ) is not known in the case of a 
product-based optimization and thus cannot be specified at 
the input station 184, a current total procedure time (t P ^) 
initially will be assumed (e.g., this assumption is configured 
in the optimizer model 172 and since a range of total 
procedure times is provided in the prediction model as noted 
above, the mean total procedure time (t P ) is typically con- 
figured into this portion of the optimizer model 172 as the 
initial current total procedure time (tp.^). The "current" 
designation is used for the total procedure time in this case 
since the optimizer model 172 provides for an adjustment of 
the total procedure time after each iterative determination of 
the inlet flow (Q^) which provides the specified AC infu- 
sion rate (Ispec) m order to achieve the desired yield (Y) if 
required in the case of a product-based optimization as will 
be discussed in more detail below. 

[0310] The solution of Eqs. 4, 8, 14, and 16 also requires 
that certain values initially be assumed for certain of the 
remaining parameters. In this case, an iterative procedure is 
used in the solution of the yield equation (Eq. 4) (and 
including equations ancillary thereto as noted above) and 
updated values are used in the next iterative calculation^) at 
the processing station 188. Although the derivation of that 
inlet flow (Q w ) which provides the specified (typically 
maximum) AC infusion rate (Isfec) may be accomplished in 
a variety of manners via Eqs. 4, 8, 14, and 16, one way is to 
assume a current value for the plasma colled factor (P), then 
calculate the current inlet flow (Q IN _c) using the specified 
AC infusion rate (I SP ec)> men calculate the current yield 
(Y c ), then calculate the current plasma collection factor (P c ) 
using the current yield (Yc)> and repeat the foregoing with 
the updated parameters, all within the processing station 
188, until there has been acceptable convergence on the 
current inlet flow (Q IN _c) in relation to the specified AC 
infusion rate (I SP ec)- 

[0311] In addition to the calculation of the current inlet 
flow (Qi N _c) associated with the specified AC infusion rate 
0spec)> tne above-discussed optimal inlet flow (QJ is 
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calculated at processing station 192. Consequently, a com- 
parison can be made between the current inlet flow (Q IN<: ) 
which was derived in the above-described manner and the 
optimal inlet flow (QJ at the first comparator 176. If the 
current inlet flow (Q IN _c) is less than the optimal inlet flow 
(Ql) at the first comparator 176, the specified values for the 
various parameters associated with the inlet flow are 
"optimum", namely the AC ratio (R) and the AC infusion 
rate (I) specified at the input station 184. Thereafter, the 
current yield (Y^) (which was calculated in the derivation of 
the current inlet flow (Q^c) associated with the specified 
AC infusion rate (I SPEC ) at the processing station 188) is 
compared with the input yield (Y) at second comparator 180. 
In the event that there has been acceptable convergence 
between these yield values, the current total procedure time 
(tp-c) is also "optimal". However, in the event that there has 
not been acceptable convergence between these yield val- 
ues, the current total procedure time (tp.^ is adjusted at 
adjusting station 196 and the foregoing iterative derivation 
of the current inlet flow (Q IN _c) associated with the specified 
AC infusion rate (I S pec) ^ repeated until such convergence 
is achieved (i.e., using the initially specified AC infusion rate 
('spec) anc * me now adjusted current total procedure time 
(t P . c , a new current inlet flow (Qi N _c) is iteratively derived 
in the above-described manner). 

[0312] Referring back to the first comparator 176, if the 
current inlet flow (Q^c) associated with the specified AC 
infusion rate (I S pec) derived at processing station 188 is 
greater than the optimal inlet flow (Ql), a current AC 
infusion rate (!<-) associated with this particular inlet flow 
(Ql) is iteratively derived at the processing station 188 
generally in the above -described manner (i.e., the initially 
specified AC infusion rate (I S p E c) k disregarded in this 
derivation and a current AC infiision rate (1^ is iteratively 
derived to coincide with the inlet flow (Ql))- In this case, the 
current inlet flow (Q^^) will always be equal to the optimal 
inlet flow (QJ at the first comparator 176 and the optimizer 
model 172 thereafter proceeds to the second comparator 180 
for the yield comparison in accordance with the above - 
described procedure. 

[0313] The optimizer model 176 may also be used for a 
time-based optimization. In this case, the total procedure 
time (t p ) is specified at the input station 184 as a specified 
total procedure time (t P _sp EC ) and thus is not assumed as in 
the product-based optimization. The optimizer model 172 
thereafter proceeds in the same manner discussed above 
with regard to the product-based optimization except at the 
second comparator 180. Since no yield was input there is no 
yield comparison made at the second comparator 180. 
Instead a total procedure time comparison is made at the 
second comparator 180. Since the current total procedure 
time (tp^) was set equal to the specified total procedure time 
Op-spec) pn° r *° me model 172 proceeding to the processing 
station 188 in this time-based optimization, the model 172 
will exit each time at the second comparator for a time-based 
optimization. 

[0314] In addition to the above-described product-based 
and time-based optimizations, the principles of the present 
invention may be extended to other applications relating to 
enhancing blood component system management. For 
instance, an optimization in accordance with principles of 
the present invention may be extended to encompass donor 
management issues. In one such case, another "optimiza- 



tion" associated with the blood component collection pro- 
cess would be to collect blood components as dictated by 
existing inventory (i.e., use optimization as an inventory 
control). That is, information relating to the inventory of the 
various types of blood components in the blood bank/center 
and/or the demand for one or more blood component types 
could be maintained such that specific collection procedures 
could be selected to accommodate for a low supply of a 
given blood component type and/or a high demand for such 
blood component type. More specifically, in the event that 
the supply of red blood cells was low and/or the demand for 
red blood cells was high, or anticipated to be so in the near 
future, prompts could be provided to operators that red blood 
cells should be selected for collection if possible from 
donors during a given time period. Relatedly, the optimiza- 
tion principles of the present invention would be applicable 
to maintaining data on blood component collections from a 
given donor such that a determination could be made as to 
what type or types of blood components from the particular 
donor provided the maximum yield in the collection proce- 
dure. That is, information could be collected and maintained 
from prior blood component donations such that a determi- 
nation could be made for a specific donor as to which type 
or types of blood components the donor has had a propensity 
to produce maximum yields therefor. 

[0315] Notwithstanding the foregoing description of the 
present invention in relation to an on-line blood component 
collection process, those skilled in the art will appreciate that 
the source of blood may be provided to the blood component 
collection device from an appropriate blood container (not 
shown) interconnected with the blood component collection 
device 18 versus receiving such directly from a human 
donor. Moreover, the blood of course may be provided from 
alternative sources such as animals. Furthermore, as illus- 
trated in FIG. 7B the described component (platelet, RBC, 
plasma, inter alia) harvesting procedure may be performed 
utilizing a single needle configuration. In addition, the 
present invention is applicable to the collection of other 
types of blood components such as red blood cells, stem 
cells, white blood cells, and/or plasma, and is further appli- 
cable to the simultaneous collection of more than one blood 
component type. In the case of red blood cell collection and 
optimization in accordance with principles of the present 
invention, the donor's blood type should be known and used 
in various algorithms. Moreover, the present invention is not 
limited to the source being whole blood. That is, the prin- 
ciples of the present invention may be applicable to removal 
of a component from any composite liquid, i.e. any liquid 
containing separable components (preferably separable 
using mechanical procedures. 

[0316] The foregoing description of the present invention 
has been presented for purposes of illustration and descrip- 
tion. Although the preferred embodiment of the invention 
has been described in language which may be thought 
specific to structural features, methodological acts, and 
computer readable media containing such acts, it is rather 
intended to be understood that the invention defined in the 
appended claims is not necessarily limited to the specific 
structure, acts or media so described. The specific structure, 
acts or media are disclosed as preferred forms of imple- 
menting the claimed invention. Consequently, variations and 
modifications commensurate with the above teachings, and 
skill and knowledge of the relevant art, are within the scope 
of the present invention. The embodiments described here- 
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inabove are further intended to explain best modes known of 
practicing the invention and to enable others skilled in the art 
to utilize the invention, and such other embodiments, and 
with various modifications required by the particular appli- 
cations or uses of the present invention. It is intended that the 
appended claims be construed to include alternative embodi- 
ments to the extent permitted by the prior art. 

What is claimed is: 

1. An extracorporeal blood processing information man- 
agement system comprising: 

a central database; 

a data input device connected in data communication 
relationship with said central database; 

a data manipulation device connected in data communi- 
cation relationship with at least one of said central 
database and said data input device; and 

a communication subsystem connected in data commu- 
nication relationship with at least one of said central 
database, said data input device and said data manipu- 
lation device; and 

at least one extracorporeal blood processing machine; 

whereby said communication subsystem is connected in 
data communication relationship with said at least one 
extracorporeal blood processing machine to provide for 
data communication to and from said at least one 
extracorporeal blood processing machine; 

whereby said communication subsystem communicates 
data to said at least one extracorporeal blood processing 
machine, said data being preparation data which is 
generated by said data manipulation device and is used 
by said at least one extracorporeal blood processing 
machine in preparation of said at least one machine for 
an extracorporeal blood processing procedure; and 

whereby said communication subsystem communicates 
data from said at least one extracorporeal blood pro- 
cessing machine, whereby said data is run data which 
represents information about an extracorporeal blood 
processing procedure run on said at least one blood 
processing machine. 
2. An extracorporeal blood processing information man- 
agement system adapted to be used with at least one extra- 
corporeal blood processing machine, said system compris- 
ing: 

a central database; 

a data input device connected in data communication 
relationship with said central database; 

a data manipulation device connected in data communi- 
cation relationship with at least one of said central 
database and said data input device; and 

a communication subsystem connected in data commu- 
nication relationship with at least one of said central 
database, said data input device and said data manipu- 
lation device; 

whereby said communication subsystem is also adapted to 
be connected in data communication relationship with 
at least one extracorporeal blood processing machine to 



provide for data communication to and from said at 
least one extracorporeal blood processing machine; 

whereby said communication subsystem is adapted to 
communicate data to said at least one extracorporeal 
blood processing machine, said data being preparation 
data which is generated by said data manipulation 
device and is used by said at least one extracorporeal 
blood processing machine in preparation of said at least 
one machine for an extracorporeal blood processing 
procedure; and 

whereby said communication subsystem is adapted to 
communicate data from said at least one extracorporeal 
blood processing machine, whereby said data is run 
data which represents information about an extracor- 
poreal blood processing procedure run on said at least 
one blood processing machine. 

3. An extracorporeal blood processing information man- 
agement system according to claim 2 whereby said prepa- 
ration data is derived from data communicated from said 
central database to said data manipulation device. 

4. An extracorporeal blood processing information man- 
agement system according to claim 2 whereby said prepa- 
ration data is derived from data communicated from said 
data input device to said data manipulation device. 

5. An extracorporeal blood processing information man- 
agement system according to claim 2 in which said prepa- 
ration data is communicated from at least one of said central 
database and said data input device to said data manipulation 
device. 

6. An extracorporeal blood processing information man- 
agement system according to claim 2 in which said run data 
is communicated by said communication subsystem from 
said at least one extracorporeal blood processing machine 
during said procedure. 

7. An extracorporeal blood processing information man- 
agement system according to claim 2 in which said run data 
represents information about an extracorporeal blood pro- 
cessing procedure collected after completion of said proce- 
dure. 

8. An extracorporeal blood processing information man- 
agement system according to claim 2 in which said run data 
is communicated to said at least one extracoporeal blood 
processing machine and used by said at least one extracor- 
poreal blood processing machine in preparation of said at 
least one machine for a discrete, subsequent extracorporeal 
blood processing procedure. 

9. An extracorporeal blood processing information man- 
agement system according to claim 2 in which said run data 
is communicated by said communication subsystem to said 
central database to create stored run data, 

10. An extracorporeal blood processing information man- 
agement system according to claim 9 in which said stored 
data is communicated by said communication subsystem to 
said data manipulation device which manipulates said stored 
data to create preparation data which is communicated to 
one of said at least one extracorporeal blood processing 
machine which uses said preparation data in preparation of 
said one of said at least one machine for a discrete, subse- 
quent extracorporeal blood processing procedure. 

11. An extracorporeal blood processing information man- 
agement system according to claim 2 in which a report may 
be generated using said run data. 
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12. An extracorporeal blood processing information man- 
agement system according to claim 2 in which said prepa- 
ration data is manipulated by said manipulation device to 
create manipulated preparation data. 

13. An extracorporeal blood processing information man- 
agement system according to claim 12 in which said 
manipulated preparation data is optimized preparation data 
as a result of an optimization manipulation performed by 
said manipulation device. 

14. An extracorporeal blood processing information man- 
agement system according to claim 2 in which said central 
database receives previously stored data from a discrete 
information management system, and wherein said previ- 
ously stored data is communicated by said communication 
subsystem to said data manipulation device which manipu- 
lates said previously stored data to create said preparation 
data. 

15. An extracorporeal blood processing information man- 
agement system according to claim 14 in which said prepa- 
ration data is optimized preparation data as a result of an 
optimization manipulation performed by said manipulation 
device. 

16. An extracorporeal blood processing information man- 
agement system according to claim 2 which farther com- 
prises computer program product including: 

a module for collecting donor data; 

a module for manipulating said donor data; 

a module for assigning a donor to an extracorporeal blood 
processing system; and 

a module for finalizing an extracorporeal blood proce- 
dure. 

17. An extracorporeal blood processing information man- 
agement system according to claim 16 in which said module 
for collecting donor data includes one or more sub-proce- 
dures which prompt a user to enter data. 

18. An extracorporeal blood processing information man- 
agement system according to claim 16 in which said module 
for collecting donor data includes one or more sub-proce- 
dures which provide for receiving donor data stored in a 
discrete storage medium. 

19. A system according to claim 16 wherein said module 
for manipulating donor data includes one or more facilities 
which provide for optimizing donor data to create optimized 
donor data. 

20. A system according to claim 16 wherein said module 
for manipulating donor data includes one or more facilities 
which provide for manipulating said optimized donor data to 
create manipulated donor data. 

21. A system according to claim 16 whereby said module 
for collecting data and said module for manipulating data are 
used to obtain a prediction of a procedure for which a donor 
is qualified to undergo recruiting a donor to undergo the 
procedure. 

22. A system according to claim 16 wherein said module 
for assigning a donor to an extracorporeal blood processing 
system includes one or more facilities which provide for 
determining the availability of a donor to be assigned to an 
extracorporeal blood processing system. 

23. A system according to claim 16 wherein said module 
for assigning a donor to an extracorporeal blood processing 
system includes one or more facilities which provide for 



determining the availability of an extracorporeal blood pro- 
cessing system to which a donor may be assigned. 

24. A system according to claim 16 wherein said module 
for finalizing an extracorporeal blood procedure includes 
one or more facilities which provide for monitoring a 
procedure. 

25. A system according to claim 16 wherein said module 
for finalizing an extracorporeal blood procedure includes 
one or more facilities which provide for finalizing a proce- 
dure. 

26. A system according to claim 16 wherein said module 
for finalizing an extracorporeal blood procedure includes 
one or more facilities which provide for generating a report 
on a procedure. 

27. A system according to claim 16 which further com- 
prises a module for monitoring a procedure. 

28. A system for performing an extracorporeal blood 
collection procedure according to claim 16 which further 
comprises a reporting module for generating reports. 

29. A system for performing an extracorporeal blood 
collection procedure according to claim 16 which further 
comprises a reporting module for administrating parameters 
to be used in at least one of said module for collecting donor 
data; said module for manipulating said donor data; said 
module for assigning a donor to an extracorporeal blood 
processing system; and said module for finalizing an extra- 
corporeal blood procedure. 

30. An extracorporeal blood processing information man- 
agement system for use with one or more extracorporeal 
blood processing machines, said system comprising: 

a central database; 

a data input device connected in data communication 
relationship with said central database; 

a data manipulation device connected in data communi- 
cation relationship with at least one of said central 
database and said data input device; and 

a communication subsystem connected in data commu- 
nication relationship with at least one of said central 
database, said data input device and said data manipu- 
lation device; 

whereby said communication subsystem is also connected 
in data communication relationship with one or more 
extracorporeal blood processing machines to provide 
for data communication in at least one direction to or 
from said one or more extracorporeal blood processing 
machines; and 

whereby said communication subsystem is also connected 
in data communication relationship with a discrete 
information management system to provide for data 
communication in at least one direction to or from said 
discrete information management system. 

31. An extracorporeal blood processing information man- 
agement system according to claim 30 in which said com- 
munication subsystem communicates data from said discrete 
information management system to said extracorporeal 
blood processing information management system. 

32. An extracorporeal blood processing information man- 
agement system according to claim 31 whereby said com- 
munication subsystem further communicates the data from 
said discrete information management system to said one or 
more extracorporeal blood processing machines, said data 
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being used by said one or more extracorporeal blood pro- 
cessing machines in preparation of said one or more 
machines for an extracorporeal blood processing procedure. 

33. An extracorporeal blood processing information man- 
agement system according to claim 31, in which said data 
from said discrete information management system is 
manipulated by said data manipulation device to create 
manipulated preparation data which is communicate to said 
one or more extracorporeal blood processing machines, said 
manipulated preparation data being used by said one or more 
extracorporeal blood processing machines in preparation of 
said one or more machines for an extracorporeal blood 
processing procedure. 

34. An extracorporeal blood processing information man- 
agement system according to claim 33 in which said 
manipulated preparation data is optimized preparation data 
as a result of an optimization manipulation performed by 
said data manipulation device. 

35. An extracorporeal blood processing information man- 
agement system according to claim 30 whereby said com- 
munication subsystem communicates data from said one or 
more extracorporeal blood processing machines to said 
extracorporeal blood processing information management 
system, whereby this data is run data which represents 
information about an extracorporeal blood processing pro- 
cedure run on said one or more blood processing machines. 

36. An extracorporeal blood processing information man- 
agement system according to claim 35 whereby said com- 
munication subsystem communicates said run data from said 
extracorporeal blood processing information management 
system to said discrete information management system, 
whereby this run data represents information about an 
extracorporeal blood processing procedure run on said one 
or more blood processing machines. 

37. An extracorporeal blood processing information man- 
agement system according to claim 30 whereby said discrete 
information management system is a discrete extracorporeal 
blood processing information management system. 

38. An extracorporeal blood processing information man- 
agement system according to claim 37 whereby said discrete 
extracorporeal blood processing information management 
system is also connected in data communication relationship 
with a discrete set of one or more extracorporeal blood 
processing machines in data communication in at least one 
direction to or from said discrete set of said one or more 
extracorporeal blood processing machines. 

39. An extracorporeal blood processing information man- 
agement system according to claim 38 whereby said discrete 
extracorporeal blood processing information management 
system further includes: 

a discrete central database; 

a discrete data input device connected in data communi- 
cation relationship with said discrete central database; 

a discrete data manipulation device connected in data 
communication relationship with at least one of said 
discrete central database and said discrete data input 
device; and 

a discrete communication subsystem connected in data 
communication relationship with at least one of said 
discrete central database, said discrete data input device 
and said discrete data manipulation device; 



whereby said discrete communication subsystem is also 
connected in data communication relationship with 
said discrete set of one or more extracorporeal blood 
processing machines to provide for data communica- 
tion in at least one direction to or from said discrete set 
of one or more extracorporeal blood processing 
machines. 

40. An extracorporeal blood processing information man- 
agement system according to claim 39 whereby said discrete 
communication subsystem of said discrete extracorporeal 
blood processing information management system commu- 
nicates data to said discrete set of one or more extracorporeal 
blood processing machines, said data being communicated 
from said extracorporeal blood processing information man- 
agement system and said data being preparation data which 
is generated by said data manipulation device and used by 
discrete set of said one or more extracorporeal blood pro- 
cessing machines in preparation of said discrete set of one or 
more extracorporeal blood processing machines for an extra- 
corporeal blood processing procedure. 

41. An extracorporeal blood processing information man- 
agement system according to claim 39 whereby said discrete 
communication subsystem communicates data from said 
discrete set of one or more extracorporeal blood processing 
machines, whereby this data is run data which represents 
information about an extracorporeal blood processing pro- 
cedure run on said discrete set of one or more extracorporeal 
blood processing machines. 

42. An extracorporeal blood processing information man- 
agement system according to claim 30 whereby said discrete 
information management system is a discrete blood center 
information management system. 

43. An extracorporeal blood processing information man- 
agement system according to claim 30 whereby said discrete 
information management system is a discrete hospital infor- 
mation management system. 

44. An extracorporeal blood processing information man- 
agement system according to claim 30 whereby said discrete 
information management system is a discrete help center 
information management system. 

45. An extracorporeal blood processing information man- 
agement system according to claim 30 whereby said discrete 
information management system is a discrete internet infor- 
mation management system. 

46. An extracorporeal blood processing information man- 
agement system according to claim 30 whereby said discrete 
information management system is a discrete manufactur- 
ers^ information management system. 

47. A method for managing extracorporeal blood process- 
ing comprising the steps of: 

receiving stored donor data from a storage medium; 
manipulating said stored donor data using a data 
manipulation device to obtain manipulated data, said 
data manipulation device being disposed in data com- 
munication relationship with said storage medium and 
an extracorporeal blood processing machine; commu- 
nicating said manipulated data from said data manipu- 
lation device to said extracorporeal blood processing 
machine; and performing an extracorporeal blood pro- 
cessing procedure using said manipulated data. 

48. A method for performing an extracorporeal blood 
collection procedure including the steps of: 

collecting donor data; 
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manipulating said donor data to create manipulated donor 
data; 

assigning a donor to an extracorporeal blood processing 
system including sending said manipulated donor data 
to the extracorporeal blood processing system; 

running an extracorporeal blood collection procedure 
using said manipulated donor data and creating run 
data; and 

finalizing an extracorporeal blood collection procedure. 

49. A method according to claim 48 wherein said step of 
collecting donor data includes receiving donor data from a 
storage medium, and wherein said step of manipulating said 
donor data includes manipulating the donor data received 
from said storage medium. 

50. A method according to claim 48 wherein said step for 
collecting donor data includes one or more facilities for 
prompting a user to enter data. 

51. A method according to claim 48 wherein said step for 
collecting donor data includes one or more facilities which 
provide for receiving donor data stored in a discrete storage 
medium. 

52. A method according to claim 48 wherein said step for 
manipulating donor data includes one or more facilities 
which provide for optimizing donor data to create optimized 
donor data. 

53. A method according to claim 48 wherein said step for 
manipulating donor data includes one or more facilities 
which provide for manipulating said optimized donor data to 
create manipulated donor data. 

54. A method according to claim 48 whereby said step for 
collecting data and said step for manipulating data are used 
to obtain a prediction of a procedure for which a donor is 
qualified to undergo recruiting a donor to undergo the 
procedure. 

55. A method according to claim 48 wherein said step for 
assigning a donor to an extracorporeal blood processing 
system includes one or more facilities which provide for 
determining the availability of a donor to be assigned to an 
extracorporeal blood processing system. 

56. A method according to claim 48 wherein said step for 
assigning a donor to an extracorporeal blood processing 
system includes one or more facilities which provide for 
determining the availability of an extracorporeal blood pro- 
cessing system to which a donor may be assigned. 

57. A method according to claim 48 wherein said step for 
finalizing an extracorporeal blood procedure includes one or 
more facilities which provide for monitoring a procedure. 

58. A method according to claim 48 wherein said step for 
finalizing an extracorporeal blood procedure includes one or 
more facilities which provide for finalizing a procedure. 

59. A method according to claim 48 wherein said step for 
finalizing an extracorporeal blood procedure includes one or 
more facilities which provide for generating a report on a 
procedure. 

60. A method according to claim 48 which further com- 
prises a step for monitoring a procedure. 

61. A method according to claim 48 which further com- 
prises a step for generating reports. 

62. A method according to claim 48 which further com- 
prises a step for administrating parameters to be used in at 
least one of said steps for collecting donor data; for manipu- 



lating said donor data; for assigning a donor to an extracor- 
poreal blood processing system; and for finalizing an extra- 
corporeal blood procedure. 

63. A method according to claim 48 in which each of said 
steps may be performed at any time during an extracorporeal 
blood processing procedure. 

64. A method according to claim 48 in which said step for 
collecting donor data produces a cbecked-in donor record 
which contains said donor data; said checked-in donor 
record being used by said step for manipulating donor data 
to create manipulated donor data. 

65. A method according to claim 48 in which said step for 
manipulating produces a manipulated donor data record 
which contains said manipulated donor data; said manipu- 
lated donor data record being used by said step for assigning 
a donor to an extracorporeal blood processing machine to 
assign a donor to a machine. 

66. A system for performing an extracorporeal blood 
collection procedure including a computer program product 
comprising: 

a module for collecting donor data; 

a module for manipulating said donor data; and 

a module for assigning a donor to one of one or more 
extracorporeal blood processing systems; and 

a module for finalizing an extracorporeal blood proce- 
dure. 

67. A method for managing extracorporeal blood process- 
ing activities comprising the steps of: 

using a centralized system to run a prediction using donor 
data; 

obtaining a prediction of a yield for a extracorporeal 
blood procedure for which a donor is qualified to 
undergo; 

contacting the donor to recruit the donor to undergo the 
procedure. 

68. A method according to claim 67 in which the central- 
ized system comprises a database, and a data manipulation 
device. 

69. A method according to claim 67 in which step of using 
a centralized system comprises collecting donor data, and 
manipulating said donor data. 

70. A method according to claim 69 in which step of 
collecting donor data comprises receiving data from a dis- 
crete storage medium. 

71. A method according to claim 69 in which step of 
collecting donor data comprises receiving data from a data 
input device. 

72. A method according to claim 69 in which step of 
manipulating donor data comprises running an optimization 
on said donor data to obtain optimized donor data. 

73. A method according to claim 72 in which step of 
manipulating donor data comprises running an optimization 
on said donor data to obtain optimized donor data. 

74. A method according to claim 73 in which step of 
running an optimization on said donor data to obtain opti- 
mized donor data further comprises obtaining a prioritiza- 
tion of potential procedures. 

75. A method according to claim 67 which is used to 
control inventory. 

76. A method according to claim 67 which is performed 
without the specific potential donor present. 
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77. A method according to claim 67 which is performed 
tailor its blood and blood component supply to better match 
demand. 

78. A method for prioritizing extracorporeal blood com- 
ponent collection procedures comprising the steps of: 

manipulating donor data on a data m amputation device to 
obtain manipulated data; 

communicating said manipulated data to an extracorpo- 
real blood processing machine; and 

performing an extracorporeal blood collection procedure 
using said manipulated data. 

79. A method for managing extracorporeal blood compo- 
nent collection according to claim 78 wherein said manipu- 
lated data is process control data. 

80. A method for managing extracorporeal blood compo- 
nent collection according to claim 78 wherein said manipu- 
lated data is optimized process control data. 

81. A method for managing extracorporeal blood compo- 
nent collection according to claim 78 further comprising the 
step of communicating run data from said extracorporeal 
blood processing machine to said data manipulation device. 

82. A method for managing extracorporeal blood compo- 
nent collection according to claim 81 further comprising the 
step of generating a report using said run data. 

83. A method for collecting at least one predetermined 
type of blood component from a source of whole blood using 
a blood component collection system comprising a blood 
component oollection device and a collection procedure, 



said collection procedure having a plurality of control 
parameters associated therewith, said method comprising 
the steps of: 

providing biological data relating to said source of whole 
blood; 

obtaining historical data from a centralized database; 
identifying at least one of a desired yield of said at 
least one predetermined blood component or a time 
period for duration of the collection procedure; 

performing a first deriving step comprising deriving a 
magnitude for at least one of said control parameters 
from at least two of said providing, obtaining and 
identifying steps; 

using said magnitude of said at least one of said control 
parameters obtained during said first deriving step to 
control the operation of said blood component collec- 
tion system; and 

performing said collection procedure on said blood com- 
ponent collection device using said at least one of said 
control parameters obtained during said first deriving 
step to control at least one of the collection of said 
desired yield of said at least one predetermined blood 
component from said source of whole blood or the time 
period of duration of said collection procedure. 

***** 
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UNOS VITALINK BUSINESS SYSTEM CONCEPT 



1, EXECUTIVE SUMMARY 

American Management Systems, Inc. (AMS) is pleased to present the United 
Network for Organ Sharing (UNOS) with the first deliverable of the Vitalink 
prototype, the Business System Concept Document. AMS combines extensive 
mobile computing technology expertise with the wireless communication 
experience necessary to develop the Vitalink system. AMS is looking forward to 
developing a partnership with UNOS in the development and implementation of a 
full-scale Vitalink system. AMS, headquartered in Fairfax, Virginia, is one of the 
nation's largest consulting and development firms with over 30 offices worldwide. 

Vitalink is a data collection tool designed for the unique requirements of the 
organ sharing community. It is application software combined with pen-based, 
hand-held computers and wireless data communications. Vitalink will not 
dramatically change or re-engineer the current donor data collection process, 
rather it will compress the existing process so that a recipient can be found for 
an organ in the least amount of time. UNOS's number one objective for Vitalink 
is to save lives by reducing the amount of time it takes to find a suitable 
recipient. 

Vitalink will be used by the Organ Procurement Coordinators in the field to collect 
and transmit the essential donor information to the UNOS Organ Center so that 
a match run can be executed on the existing system at UNOS. Vitalink provides 
a mechanism to standardize the data that is collected on donors to increase the 
chance of organ placement. Vitalink allows the coordinators to collect and 
transmit the donor data wherever and whenever the information becomes 
available. 

The Vitalink prototype automates the data on the Association of Organ 
Procurement Organizations 1 (AOPO) form. The plan is to deliver the front-end 
user interface in early January, 1994. The back-end wireless communications 
will be incorporated by the end of January, 1994 for prototype delivery in 
February. Full-scale implementation is planned for late summer of 1994 after a 
thorough review of the prototype feedback. 
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2. INTRODUCTION 



This document is the blueprint for development and implementation of the 
Vitalink prototype system. Like a blueprint for a building, it addresses the 
purpose of Vitalink, what Vitalink will include and how Vitalink will be built. This 
document also addresses the development of a partnership between AMS and 
UNOS to develop a complete production system of Vitalink by the summer of 
1994. 

The key to the design of Vitalink is a comprehensive, but user friendly interface 
combined with seamless communications. The organ sharing environment is in 
a constant fight against time. The Vitalink system will promote the use of 
accurate, quality data that can be used to find a recipient for an organ in the 
least amount of time possible. 

The initial plan to release a prototype of the Vitalink system by January, 1994 
was developed as a cost-effective way to perform a proof-of-concept study and 
begin the relationship between AMS and UNOS in the development of a 
production version of Vitalink. 

This document is created to be a living guide to the overall design and 
construction of Vitalink. Changes to Vitalink's purpose and design are certain to 
occur over time. These changes should be incorporated in this document since 
it is the cornerstone of the Vitalink system. 

The Business System Concept begins with an overview of Vitalink. An approach 
section follows and includes a detailed description of the communication tools 
that will be applied in the Vitalink application. A projected cost and development 
schedule are also included in this document. 
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3. BACKGROUND 



3.1 United Network for Organ Sharing (UNOS) 

Originally established in 1977 by members of the South-Eastern Organ 
Procurement Foundation (SEOPF), the United Network for Organ Sharing 
(UNOS) operates the national Organ Procurement and Transplantation Network 
(OPTN) and the national Scientific Registry for Organ Transplantation. In this 
role, UNOS functions as both a contractor for the federal government and as a 
private, non-profit corporation. Under contract with Health Resources and 
Services Administration (HRSA), UNOS has operated the OPTN since 
September 30, 1986, and the Scientific Registry since September 30, 1987. 

In October of 1984, Congress passed The National Organ Transplant Act 
(NOTA), which provided for the establishment of a Task Force on Organ 
Procurement and Transplantation, an Organ Procurement and Transplantation 
Network, and a Scientific Registry for Organ Transplantation. In 1986, upon 
completion of the work of the Task Force, HRSA called for proposals to establish 
the OPTN. In September 1986, a contract was awarded to UNOS to operate the 
OPTN. In September 1987, UNOS was awarded a separate contract to 
establish and operate the Scientific Registry for Organ Transplantation. Both 
contracts were renewed in 1990 and 1993 for three years. 

The OPTN and Scientific Registry contracts are administered by the Division of 
Organ Transplantation, a division of HRSA, within the Department of Health and 
Human Services (DHHS). Under the terms of these contracts, UNOS conducts 
numerous projects to meet federally-established goals of the OPTN and the 
Scientific Registry. As required by the Scientific Registry contract, all data 
collected and generated under the contract are the exclusive property of the 
United States Government. 

The purpose of the Scientific Registry, as stipulated in the NOTA of 1984, is the 
collection of data for continuous evaluation of the clinical and scientific status of 
transplantation in the United States. The specific goals of the Registry are the 
following: 1) to collect, in a computer system, data on all transplant recipients 
and all transplant programs in the US, 2) to provide a database enabling periodic 
analysis and reporting of transplantation effectiveness, nationwide, and 3) to 
provide a national database for basic and clinical research on organ 
transplantation. The Scientific Registry collects data about recipient status at the 
time of transplant and at time of post-transplant hospital discharge. The Registry 
also collects follow-up data on transplant recipients until two years following graft 
failure or until the patient dies, regardless of the cause of death. 

Since its inception, the purpose of the OPTN has been "...to improve the 
effectiveness of the nation's organ donation, procurement, and transplantation 
system by increasing the availability of and access to donor organs for patients 
with end-stage organ failure." 1 In an effort to achieve these goals, the OPTN 



1 From HRSA Request for Proposals for OPTN contract 
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operates and maintains a national computer list of patients waiting for kidney, 
heart, heart/lung, lung, liver, and pancreas transplants. It also maintains a 
computer-assisted system for allocating organs to individuals on the waiting list, 
as well as an Organ Center allowing 24-hour access by all transplant programs 
in the US to the donor/recipient matching system. Data collected by the OPTN 
pertains to patients waiting for transplants, donors and recipients of donated 
organs, donor/recipient matching and organ allocation, and donor/recipient 
histocompatibility. In order to operate the OPTN, UNOS has adopted corporate 
by-laws and policies governing membership standards, organ allocation, and 
data management. 

UNOS members fall into one of two categories: 1) institutional members and 2) 
public members. Institutional members include transplant centers, independent 
organ procurement organizations, and independent tissue typing laboratories. 
Among public members are 1) private, non-profit voluntary health organizations 
which promote organ donation or which serve interests of transplant patients and 
their families, 2) private, non-profit medical/scientific organizations involved in 
transplantation, or 3) representatives of fields such as theology, ethics, health 
care financing, and other areas. 

For administrative purposes, UNOS has divided the country into eleven 
geographic regions. Each region is assigned a UNOS staff administrator to 
assist in coordinating regional activities. Additionally, each region is represented 
on the Board of Directors and on each of UNOS's permanent standing 
committees. 

3.2 American Management Systems, Inc. 

American Management Systems, Inc. is based in Fairfax, Virginia. Founded in 
1970, AMS specializes in the helping clients improve their performance through 
the intelligent use of information technology. AMS combines specific industry 
experience, business function expertise, proven systems development practices, 
and an extraordinary depth of technological competence to help our clients meet 
their business goals. 

AMS is a trusted business partner for many of the largest and most respected 
organizations in the markets in which we specialize. We derive approximately 
85% of our business each year from clients with whom we worked in the 
previous year. 

AMS mobilizes specific industry experience, functional expertise, and technical 
resources to serve clients worldwide. AMS's 3,700 employees serve clients from 
our headquarters in Fairfax, Virginia and from offices in over 30 cities throughout 
North America and Europe. AMS has sustained an annual growth rate of 
approximately 20% for the past decade. Our revenues for 1992 were $333 
million. 

AMS's technology leadership in mobile computing is well known by government 
and industry. We have invested significantly in research and development to 
improve our knowledge of portable computers and wireless communications so 
that we can better assist our customers. The AMS Mobile Computing Center 
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has developed over twenty production and prototype systems in the last two 
years for some of the largest government and Fortune 500 organizations. The 
total potential user audience for AMS mobile systems will eclipse 2500 users b< 
the end of 1994. 



3.3 Vitalink Partnership 

UNOS and AMS were introduced in 1992 by GRiD Systems, Inc., the industry 
leader in mobile computers. Greg Pellegrino, AMS's Director for Mobile 
Computing, met with Dave Klein, UNOS Director of Computer Services, to 
discuss the application of hand-held computers and wireless communications to 
the organ placement process. AMS combined proven methods and previous 
mobile computing experience to design a prototype development approach for 
UNOS. 

Vitalink is the name given by UNOS to the future system developed through this 
collaborative effort to apply state of the art technology for gathering and 
disseminating electronic data directly from the donor site. Vitalink's benefits will 
yield improvements throughout the organ data management process. 

AMS is contracted to develop the initial Vitalink prototype. AMS's initial 
approach is based on a quick schedule and practical cost in the spirit of 
establishing a long-term partnership with UNOS. This document is the first 
deliverable produced by this relationship, and will lay the cornerstone for defining 
a plan for the full implementation of Vitalink. 



3.4 Technology Trends 

There are three absolute trends in the evolution of computer technology: 

1 . They are getting more powerful. 

2. They are getting smaller. 

3. They are getting cheaper. 

While some experts argue the merits of one computer or another, one operating 
system versus another, or one Graphical User Interface (GUI) versus another, 
these three trends will forever affect the successful application of computers to 
improve business performance. 

It is interesting to note that since the day Charles Babbage completed his 
programmable machine in 1870, computers served much the same purpose as 
his original device for over 100 years. Crunching numbers was and still 
continues to be the most common use of the world's most powerful computing 
devices. After all, the word computer originally referred to a person who 
performed mechanical calculations. 

It is not so significant that the personal computer invented in the 1970's was 
smaller than its predecessors. The significance was the potential the smaller 
computing device would have for the productivity of individuals. The computer is 
still immature in its application to improve the productivity of individuals and 
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All significant technological innovations have had a similarly long gestation 

f^r^Lhl * ,S ' ? e technol °9y user t00k a lon 9 time to figure out how to put it to 
use without creating new problems. The types of problems that are most 
common are cultural acceptance, fragility or added work. Yes. additional work 
nas often been required during the long periods of technology adoption. 
An example of this was provided by Michael Rothschild in his article "The 
Comms I Productivity Surge." Forbes ASAP Magazine. March 29 1993 
Rothschild uses this example of the electric motor and its impart on 
manufacturing: K 

"As the 20th century began, business investment in electrical 
equipment skyrocketed. Between, 1900 and 1920 the percentage of 
US factories equipped with electric motors jumped from five percent 
to f Ay-five percent. Yet, despite the obvious advantages of electric 
motors over steam engines, worker productivity showed almost no 
measurable increase. 

Solving the riddle of today's computer productivity is simple once its 
century-old predecessor is understood. Back then, a state-of-the-art 
facility was a three- or four-story brick building. A coal-fired steam 
engine sat in the factory's basement. Its power was transmitted to 
the equipment on the floors above through an elaborate system of 
vertical and horizontal shafts and drive belts. 

Factory owners began replacing steam engines with large electric 
motors because the new technology slashed coal bills by 20 to 60 
percent. But the power generated by these first electric motors was 
still conveyed to lathes, drills, grinders and punch presses by the 
conventional system of shafts and belts. As time passed and 
somewhat smaller electric motors became affordable, separate 
motors were installed on each floor. This eliminated the need for the 
vertical shaft. However, because the motors were still relatively 
expensive, each one powered a group of machines via horizontal 
shafts and belts. 

Electric motor technology was indeed revolutionary, but to pay for 
itself it had to be grafted onto the existing industrial infrastructure 
Multistory factories made sense in the steam age because they 
reduced the costly friction losses incurred as horizontal shafts carried 
power to the equipment. Single-floor factories would have eliminated 
all the labor wasted moving unfinished goods from floor to floor but 
overall it was cheaper to staff the elevators than to pay for the 'coal 
turned to waste heat by long horizontal shafts 
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For similar reasons, machines requiring the most horsepower were 
placed near the base of each floor's horizontal shaft. Smaller, low- 
power-consuming equipment sat at the far end of the work floor. 
Again, though this arrangement made economic sense from a power- 
conservation standpoint, it made the flow of materials ridiculously 
inefficient In short, since the entire industrial infrastructure had 
evolved around the assumption of expensive steam power, factories 
were designed to be grossly inefficient in other dimensions. Once 
made, these fundamental economic trade-offs endured for decades. 

It wasn't until cheap, small electric motors became available in the 
1920s that factories began to abandon "group drive " power for the 
"unit drive" approach, the familiar present day system in which each 
machine is powered by its own internal motor. As this technology 
was installed, companies ripped out their drive shafts and belts, 
rearranged their machines and smoothed their flow of materials. The 
most innovative high-tech firms - companies in fast-growing, new 
industries such as cigarettes, organic chemicals and electrical 
equipment - were the first to go all the way and take the radical step 
of building single-story factories. They were literally the first flattened 
corporations. 

Finally, forty years after Edison's breakthroughs, productivity growth 
took off. Where the annual labor productivity growth had hovered 
around one percent for the first two decades of the century, it jumped 
j to more than five percent a year during the Roaring Twenties". 

Michael Rothschild, The Coming Productivity Surge", Fortes ASAP Magazine, March 29, 1993 

Rothschild's analogy is included here to better understand the natural pace with 
which we figure out the right ways to apply technology. Motors were initially 
used to provide a continuous source of lower cost power. Likewise, computers 
initially provide a consistent, quick way of performing large calculations. Our 
understanding of these complex tools evolves once we address short term 
objectives (speed and reduced cost) while improving the form-factor (smaller and 
smaller), and solving new social impact issues as well. 

This brings us to the question of the value of computer technology for 
productivity. What is productivity? Simply, productivity is a measure of useful 
outputs. Even though reduced energy costs were a primary motivator in 
adapting the electric motor, it is the re-engineered manufacturing processes that 
improved individual productivity. 

Today's technology trends address form-factor and flexibility for information 
management. Smaller computers give us more capacity and capability wherever 
we need to manage information, just as miniature motors provide rotating 
machinery for the smallest process in a factory. New databases, wireless 
communications and application software tools provide the flexibility necessary 
to avoid new burdens for information workers, just like small motors that can be 
placed anywhere. 

I Vitalink is important because it capitalizes on the evolution of both information 

technology and the way we make use of it. There are still "shafts and pulleys" in 
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the organ transplantation process today. Vitalink enables coordinators to quickly 
disseminate vital organ information at the donor site and get quick feedback 
Like the motor in Rothschild's example, Vitalink does not change processes 
itself. Rather, Vitalink will support a compressed workflow that will yield benefits 
to decision makers and stakeholders, including the donor families and recipients. 

3.5 System Concept Study 

AMS firmly believes in performing an initial requirements study with the 
developers and users of an information system. This process establishes a solid 
foundation for software development and a strong sense of ownership for the 
future users of the Vitalink system. 

Representatives from AMS and UNOS met on Tuesday November 9 1993 at 
UNOS headquarters in Richmond, Virginia. This initial meeting outlined the 
goals, objectives and schedule of the Vitalink prototype system. By early 
January, 1994 UNOS and AMS will produce an operational prototype for the 
donor data collection process. The back-end communications will be ready for 
prototype delivery in February, 1994. The location and number of test sites will 
be determined by UNOS before prototype delivery in February. The specific 
hardware to be used for the prototype will be determined after AMS presents 
UNOS a review of the pen-based products of several hardware vendors. The 
plan for full implementation of Vitalink will be developed as part of the 
partnership established between AMS and UNOS. 

November 9, 1993 Vitalink Kick-Off Meeting 

David Klein UNOS, Director of Computer Services 

Scott Hall UNOS, Vitalink Project Manager 

Dan Stockdreher UNOS, Manager of Organ Center 

Greg Pellegrino AMS, Director of Mobile Computing 

LisaWolsh AMS, Vitalink Project Manager 

AMS and UNOS representatives met again on Monday November 15, 1993 in 
Richmond to analyze the Organ Procurement process at UNOS. This meeting 
outlined the current process that is in operation to gather and transmit donor 
information from the donor site to UNOS. The current method used by the 
Organ Procurement Coordinators (OPC) in the field is time consuming and 
cumbersome. The 12 page Association of Organ Procurement Organizations 
(AOPO) form, or something like it, is either faxed to the UNOS Organ Center or 
verbally repeated to the Organ Procurement Specialist at the Organ Center 
This process is naturally prone to data entry errors or misinterpretations at the 
coordinator's and the specialist's end. The Vitalink system will promote 
consistent, accurate, quality data, without the problems inherit in a hand-written 
form-driven process. 

November 15, 1993 Preliminary Analysis Meeting 

David Klein UNOS, Director of Computer Services 

Scott Hall UNOS, Vitalink Project Manager 
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Greg Pellegrino AMS, Director of Mobile Computing 

Lisa Wolsh AMS, Vitalink Project Manager 

The following day, Lisa Wolsh and Scott Hall spent the morning at the Organ 
. Center at UNOS. Each step of the donor process was reviewed with the Organ 
Procurement Specialist on duty. The entire 12 page AOPO form was discussed 
to review the attributes of the form and determine how Vitalink could improve the 
process for the Organ Procurement Specialist at the Organ Center. 

The afternoon was spent with Dan Stockdreher reviewing the AOPO form to 
place an order of precedence on the essential data which Vitalink will send to 
UNOS initially to get the donor process moving at a rapid pace. Each section of 
the form was carefully evaluated and analyzed to determine how the current 
paper form would most effectively be presented in an electronic format. 

November 16, 1993 Tour of Organ Center and Review of AOPO Form 

Scott Hall UNOS, Vitalink Project Manager 

Dan Stockdreher UNOS, Manager of Organ Center 

Gray Granger UNOS, Organ Procurement Specialist 

Lisa Wolsh AMS. Vitalink Project Manager 

A meeting was arranged with Virginias' Organ Procurement Agency (VOPA) to 
review the donor data collection process from the OPOs and the individual 
coordinator's level. AMS learned that about one-half of the existing OPOs use 
the AOPO standard donor data collection form. The OPOs take the hand-written 
donor data form and re-enter the information into a database system for future 
reporting and reimbursement. Much of the data that is on the AOPO form is 
used again on subsequent forms required by UNOS and other involved parties. 
The idea of a mobile, pen-based, wireless communication software package to 
automate the donor data collection process was very well received by the VOPA 
Organ Procurement Coordinators. 

November 19, 1993 Meeting with VOPA in Richmond and Charlottesville 

Scott Hall UNOS, Vitalink Project Manager 

Lisa Wolsh AMS. Vitalink Project Manager 

Janice Watson VOPA, Executive Director 

Gloria Taylor VOPA, Director of Education 

Kevin Myer VOPA. BS, CPTC Organ Procurement Coordinator 

Tim Johnson VOPA. BSN. RN. PTC Organ Procurement 

Coordinator 

Lorelle Myer VOPA. Data Coordinator 

Another meeting with the Indiana OPO is scheduled for December 10, 1993 in 
Indianapolis, Indiana. 
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4. APPROACH 



Users of mobile computing technologies like pen-based computers and wireless 
communications often improve organizational effectiveness through re- 
engineered business processes. The role of these technologies is to enable the 
new processes. The justification to invest in these technologies comes from the 
financial benefits derived from the new processes. New processes achieved 
through the application of mobile computing can provide cost savings added- 
cost avoidance or competitive advantage. 

Vitalink is different because it initially does not change the business processes 
related to organ procurement and transplantation. The UNOS Vitalink system 
uses these new information technology tools to carry out their critical mission 
This initial justification model is called Strategic Match. Strategic match is the 
alignment of information technology investments with the organization mission 
and goals. A strategic match approach often yields cost savings, cost-avoidance 
and competitive advantage, however those benefits are secondary to the global 
benefits of alignment. 

The following statements illustrate this by describing the Health Resources and 
Services Administration (HRSA) goals for the National Organ Procurement and 
Transplantation Network (OPTN): 

. Improve the effectiveness of cadaver organ procurement and distribution. 

. Increase patient access to state-of-the-art transplantation technology. 

. Improve the system for sharing renal and extra-renal organs so as to 

. facilitate matching of donors and recipients, based on specific criteria 
established for each organ, 

* improve transplantation outcomes, 

. provide a system by which immunologically sensitized patients are 
afforded the best possible opportunity to be matched with a 
compatible donor, and 

.. decrease the wastage of organs. 

. Assure quality control by collection, analysis, and publication of data on 
organ donation, procurement and transplantation. 

. Maintain and improve professional skills of those involved in organ 
procurement and transplantation. 

Vitalink supports improvements in each of these areas. 



4.1 What Is Vitalink? 

Vitalink is the combination of a pen-based computer, wireless communications 
and specialized software to automate the organ donor data collection process 
Vitalink is not a new process, but rather a modified, compressed version of the 
current donor data collection process. Vitalink will impact three levels of 
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organizations and individuals; UNOS. Organ Procurement Organizations and 
Organ Procurement Coordinators. Vitalink's role in each level is discussed in the 
following sections. 

4.2 What Does Vitalink Do for UNOS? 

UNOS's vision for Vitalink is to help save lives. Plain and simple. Vitalink is the 
automated version of a paper-driven, time-consuming donor data collection 
process. The amount of data needed for a potential donor will not be reduced 
but Vitalink will help in the collection and transmission of that data to UNOS so 
that a recipient can be found as quickly as possible. Vitalink will be the vehicle 
used to collect standard donor data and send this data to UNOS. The Organ 
Center will initially receive this data in a paper report format, but will eventually 
receive this data into its computer system for on-line review to execute a match 
run. 

Vitalink will ultimately be able to transmit the donor data to the Organ Center 
which will receive the data on-line. The Organ Center will then run the match 
and forward the donor data to the top thirty or forty transplant centers where the 
potential recipients are registered. Currently, the essential donor data is 
reaching at most five transplant centers per hour after a match run has been 
made. Vitalink will allow the Organ Procurement Specialist (OPS) at the Organ 
Center to spend more time finding a suitable recipient and less time tracking 
down donor data that is illegible or data that has been omitted or misinterpreted 
The OPS will now receive standard data through Vitalink. 

Vitalink will establish a close link between UNOS and the Organ Procurement 
Organizations working together for the common goal of saving lives. Vitalink will 
provide UNOS with leading edge technology to improve the performance of a 
paper driven data collection and dissemination process. UNOS will maintain and 
extend its leadership in the organ sharing community. UNOS will demonstrate to 
the Department of Organ Transplantation its ability to use advanced technology 
through Vitalink in the continuing effort to improve the OPTN and the accuracy of 
data collected for the Scientific Registry. 

4.3 What Does Vitalink Do for an OPO? 

Vitalink will improve the donor data collection process at the OPO level in several 
areas. Vitalink will be able to export donor data into a common relational 
database format that can be easily pulled into existing databases at individual 
OPOs. Vitalink will serve as a valuable addition to the existing information 
system products that an OPO may already have. This export feature of Vitalink 
will eliminate the need for dual data entry and the errors that normally 
accompany it. 

Vitalink will improve the accuracy of the data that is collected on the donor. For 
example, each check on the donor's vital signs will be date and time stamped. 
The point when donor management begins will be accurately recorded. 
Accurate data is needed for proper reimbursement from HCFA. Vitalink will 
provide a more complete, easy to use data collection process that will record the 
actual expenses incurred by the OPO in the donor management process. 
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Vitalink could reduce the time between data capture and reimbursement since it 
eliminates a time consuming data entry step. 

The number one goal of Vitalink is to get the essential donor information to 
UNOS as quickly as possible so that the donor's organs can be matched to a 
recipient on the waiting list. Approximately sixty people die a day waiting for an 
organ transplant. In addition to the lifesaving aspects of Vitalink, there are 
business risks at stake for the OPO when trying to recover organs from a donor. 
The OPO can incur costs between $6,000 to $20,000 to remove an organ from a 
donor whether or not it is placed. Vitalink will play an important role in 
transmitting the donor data to UNOS so that a recipient can be found as quickly 
as possible. The more organs that can be placed for a donor increases the 
revenue that the OPO can generate to cover the costs of organ procurement and 
placement. 

4.4 What Does Vitalink Do for an OPC? 

Vitalink will not change the process that a coordinator must go through when a 
donor becomes available. However Vitalink will change the mechanism used to 
collect and send the essential donor information to UNOS. A coordinator 
typically spends 18 to 72 hours at a donor site collecting and evaluating donor 
data in an extremely time-sensitive process. The fight against the clock is inherit 
in the donor management process. Vitalink will assist the coordinator in the 
collection and transmission of the donor data required to place the organ with an 
appropriate recipient. 

The Organ Procurement Coordinator will use Vitalink to ease the paperwork 
burden of their job. Multiple forms with much of the same data needs to be 
hand-written several times during the collection process. Initially Vitalink will 
automate the 12 page AOPO form, but ideally it will be able to produce all of the 
standard UNOS forms needed for the donor management process. 

The Vitalink system will allow the coordinator to record the donor data 
electronically on a tablet about the size of a clipboard. They will not be required 
to set up desk and chair for a portable PC, or be tied to a wall socket or fax 
machine. Instead the coordinator will be able to record the required information 
anytime, anywhere - in the hospital waiting room, at the OPO office site, or in the 
operating room. Vitalink will allow the coordinator to record donor data on the 
spot when and where it occurs. Vitalink will be the coordinators' mobile data 
collector and wireless communicator. 

Vitalink will assist the coordinator in recording more accurate data. An 
automated version of the AOPO form will provide the coordinator with valid 
options for certain data fields reducing the possibility of human error or 
misinterpretation. The coordinators will be able to customize certain parts of 
Vitalink like displaying only a list of local area hospitals and transplant centers 
instead of all the possibilities in the entire state. Vitalink will provide a standard 
mechanism to record and send donor data to UNOS. The intuitive user interface 
will be efficient and easy to use. The results sent to UNOS will be in text format, 
therefore eliminating the time consuming need for call-backs because of illegible 
handwriting. 
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4.5 Data Systems at UNOS 

Several database systems and accompanying processes support the organ 
procurement and transplantation process today. 

The OPTN Database contains pre-transplant information pertaining to transplant 
candidates on the OPTN Waiting List, donor/recipient matching, cadaveric and 
living donors, histocompatibility and potential recipients. Much of the data are 
collected through a series of forms, Feedback Records, and Match Runs. 

The Match Run is a computer program that compares transplant candidate 
characteristics stored on the OPTN Waiting List with donor information entered 
each time a cadaveric organ becomes available. For each donor organ, 
computerized matching algorithms are used to produce rank ordered lists of 
potential recipients. The matching algorithms used are based on UNOS/OPTN 
organ allocation policies, transplant center acceptance criteria and local 
variances. Each donor organ generates a separate and distinct computer list. 

The Scientific Registry database stores post-transplant information pertaining 
to organ recipients. Data are collected on organ-specific registration and follow- 
up forms. 

Because of a broad-based need, the UNOS Scientific Advisory Committee (SAC) 
has developed mechanisms through which the government, the scientific 
community, and the public can obtain access to OPTN and Scientific Registry 
Transplant data. UNOS makes data available for the study of scientific and 
policy-related issues: 

Government Access. Federal, state and local governments all utilize 
OPTN/Scientific Registry data for the development of reimbursement policy, 
performance standards, legislative and regulatory policy. 

Public and Scientific Community Access. Access to certain OPTN and 
Scientific Registry data must be made available to the public and the scientific 
community. The data are used for scientific research, policy analysis, and 
assessment of the efficacy of the organ allocation process. Current studies 
include the impact of matching on outcome, factors affecting patient waiting time, 
disease progression during the waiting period, and risk factors for graft failure. 

UNOS-Funded Research Projects. To the extent that contract funds remain 
after operational expenses have been met, UNOS has used funds to support 
research projects approved by the HRSA Project Officer. 

UNOS Data Requests. The UNOS Research Department receives requests for 
OPTN/Scientific Registry data from many different sources including the federal 
government, UNOS committees, UNOS members, UNOS staff, the media, 
private industry and other sources. 

UNOS normally provides data to any individual or organization that requests it. If 
the information or data are readily available, the information is often provided 
immediately. 
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4.6 How Does Vitalink Work? 



Current Donor Data Collection Process 1 
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Figure J 

Figure 1 above illustrates the current work flow for the donor data collection 
process. Vitalink compresses the current processes by automating the AOPO 
donor data form and sending and receiving that data via wireless 
communications. 

Figure 2 below is displayed with shaded areas which represent the areas and 
forms which Vitalink will affect. Vitalink creates a ripple affect which starts by 
transmitting the data directly from the coordinator to the UNOS Organ Center 
and trickles all the way through the process increasing efficiency and data 
accuracy. 
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Compressed Donor Data Collection Process 1 
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Figure 2 

Vitalink will send donor data directly from the coordinator to the UNOS Organ 
Center. The donor data received will be modeled after the AOPO standard data 
collection form. Initially, this information will be transmitted from the coordinator 
and printed at the Organ Center for review by the Organ Procurement Specialist 
on duty. The donor data is also stored in an ASCII file format so that the data 
can be imported into the current UNOS system by a custom batch file routine 
developed by the UNOS Computer Services staff. Once the data is entered into 
the UNOS system, a match run can be executed. Ideally the match run listing 
will be sent to the transplant centers, hospitals, OPOs and coordinators 
wirelessly. All of the preceding steps will assist in the placement of the organs. 
Eventually UNOS will be able to send out a broadcast message to the top 
potential recipients on the waiting list either by fax or on-line. 

4.7 Technical Architecture 

The system architecture for Vitalink can be divided into three primary 
components: hardware, software, and the communication link between the field 
and the UNOS office. This section provides a summary of the relationship 
between the components at each system level. 
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4.7.1 Hardware 

Field Units 

Vitalink will first be developed to run on various types of pen-based computers. 
The minimum requirements for each unit is a 40 MB hard drive, 4MB RAM, and 
the capability to use the Microsoft Windows for Pen user interface. Peripherals 
and additional equipment vary by manufacturer. 

Host Workstation 

UNOS will be equipped with a host workstation to provide the means of 
accepting the wireless communications from the individual pen-based units in the 
field. The hardware components will include a communications server, hard 
drive, monitor, keyboard, and laser printer. 
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4.7.2 Software 
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Vitalink Platform Communications Desktop Workstation 

The above figure illustrates the multiple software layers of the Vitalink 
application. The user interface allows the users to interact with the application, 
but transparent to the user is the underlying code and the operating system. 



This system uses the Windows for Pen Computing interface and will be 
developed using Microsoft Visual Basic 3.0. AMS and other third party objects 
will be used for the graphical controls and system features. Functions not 
available in Visual Basic's native mode will be developed using Microsoft C/C++. 
During the prototype, each pen-based computer will be a dedicated system and 
) only Vitalink will be accessible in the field. All other native Windows options will 

not be accessible by the user. This simplifies the system and controls the 
prototype test environment by preventing the user from having to navigate 
through layers of windows and icons to execute the application. 

4.7.3 Communications 

Data communications and transfer from remote sites will be performed using a 
wireless data network. This network will use the latest in wireless data 
transmission: cellular and packet-switched protocols. Both technologies are 
discussed in detail in section 5.3. 

4.8 User Interface 

The Vitalink application uses Multiple Document Interface (MDI) for efficient 
interaction between the user and the information on the screen. MDI is a design 
concept used by software packages like Microsoft Word and Excel. It is 
characterized by a Parent control window with smaller Child windows within the 
workspace. MDI allows users to interact among multiple forms while using 
standard menu controls and buttons. 
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4.10 Creating A New Donor File 

When a new donor is entered into the system, all current forms are saved, and 
the user is provided with a fresh report to begin the donor management process. 
Thus, a new report can be initiated at any time without losing any of the 
previously entered information. 



4. 10. 1 Selecting a Previous Donor File 

The coordinator will also be able to select a previously entered donor file, to 
review or edit some specific information, or to complete a partially entered report 
which was left unfinished at the donor site. An old record can be retrieved and 
edited by all system functions at any time. 
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Sample from the AMS Mobile Accident Reporting System 



4.10.2 The Toolbar 

Sample from the AMS Mobile Accident Reporting System 

The toolbar is a row of functional buttons that appear at the top of the display 
screen, representing all major functions of the system. Each of the AOPO 
sections can be called from the toolbar, as well as a pop-up standard keyboard, 
communication links and the Windows help system. All of the activities on the 
toolbar can also be activated from the smaller, text menu bar, located just above 
the toolbar. This arrangement follows an established Microsoft Windows 
standard and provides an easy interface to all system capabilities as well as a 
quick access to all of the most-used functions. 
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4.10:3 The Data Bar and System Interface 

The Data Bar, located just below the toolbar, and the report form workspace, are 
the system's main interface. When the coordinator selects a AOPO area from 
the toolbar, that section is shown in the workspace below. The Data Bar then 
serves as the main editing tool for the coordinator, collecting all of the data field 
information in various editor types. The Data Bar changes to react with the user 
and the form to edit each field in the report sections. Specific fields can also be 
selected non-sequentially by the user by tapping on the desired area of the 
report form. Command buttons on the Data Bar assist the user in navigating 
through the report section, clearing specified report fields, and providing context 
sensitive help based on the current field and established procedures on 
collecting the specific information. 




Sample from the AMS Mobile Accident Reporting System 



4.10.4 Data Field Editors 

There are two categories of data field editors that can appear on the Data Bar, 
data entry editors and data selection editors. The data entry editors provide the 
user with the capability of entering field information from pen/handwriting 
recognition or from keyboard input. These editors are used mainly with 
unstructured data collection, such as names and addresses. The data selection 
editors collect information that is more standardized through the use of button 
groups or code listings that apply to each field. Each editor type is described in 
detail in the following paragraphs. 

4.10.5 Numeric Entry 

The numerical editor contains a pen-aware field which recognizes the users 
handwriting and translates the electronic ink written on the screen into a 
database record. To improve the recognition rate for this editor, the pen-aware 
field has been tailored to detect only numerical information. In addition, a 
numeric keypad is included on the editor as an alternative input device. 
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4.f0.6 Text Entry 

The text editor is similar to the numerical editor, however three controls are 
included to adjust the recognition of the pen-aware field to detect alphabetic 
characters only, numeric characters only, or full alpha-numeric recognition A 
complete alpha-numeric keypad is also included to bypass the pen-aware field 
and to insure flexibility for the user. 
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4.10.7 Time Entry 

The time entry editor is a customized version of the numeric editor which does 
not rely on handwriting recognition, and follows the basic standards of time entry 
in a 24 hour format. Time fields automatically pre-fill with the current system 
time provided by the computer's internal clock, and can be easily incremented or 
decremented by the user. 
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4.10.8 Date Selection 

The date selection editor is composed of a calendar interface, in which the user 
can select the calendar day and increment or decrement the month or year Like 
the time editor, the date editor also pre-fills with the current system date which 
will rarely need to be changed by the user 
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4. 7*0.9 Gender Selection 

A simple male/female selection editor will be provided for all gender related 
fields. This editor associates the appropriate code to gender information. 




4.10.10 Listing Selection 

For all fields containing non-specialized or non-graphical selection options a text 
listing will be provided for the user to select the appropriate code number based 
on standard codes and text descriptions. These lists eliminate the need for the 
user to memorize the codes for each field. 
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4.10.11 Donor Information 

The data entry form is displayed on the screen much like the paper version. 
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Sample from the AMS Mobile Accident Reporting System 
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4.10.12 Drawings 

Diagrams and graphics will be used where applicable to assist the coordinator in 
the data entry process. In the following sample, an anatomical diagram is 
available for a social worker to "drag-and-drop" pre-defined injuries to the 
specific areas of the body. 




Sample Screen from (he AMS Child Welfare System 
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4.10.13 Narrative Information 

The Narrative Information field allows the user to enter large sections of text. 
This tool is used throughout the application wherever text must be entered. 
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Sample from the AMS Mobile Accident Reporting System 

4.10.13.1 Pre-defined Reports 

The user will be able to print the standard organ donor information forms from 
Vitalmk. All reports can be viewed and analyzed on the computer system before 
printing occurs. 

4.10.14 Utilities 

Several useful tools have been included in the Vitalink prototype to aide the 
coordinator in gathering information at the donor site. A standard alarm 
clock/stopwatch and a calculator are included in the application. The operation 
and application of these utilities are described in the following paragraphs. 



26 



ams 



' UNOS VITALINK BUSINESS SYSTEM CO NCEPT 

4.10.14.1 Alarm Clock/Stopwatch 

An alarm clock/stopwatch function, located at the bottom of the screen on the 
Status Bar, will allow the coordinator to measure the length of time spent at an 
donor site or the length of time needed for filling out the report. The alarm clock 
can also be set to denote specific times for meetings or deadlines. 

4.10.14.2 Calculator 

A calculator function can be accessed at any time. It can be set to display in 
normal or scientific mode. 



4.10.14.3 Change Password 

The system will prompt for a new password when an authorized user logs in for 
the first time. The selected password should be easy to remember but not easily 
guessed by others (i.e. birth date or name). This confidential password is used 
every time the user logs into the system to insure security of the system's data 
files. 



4.10.14.4 Pen Settings 

The user can configure the settings for the pen with this option. Settings like ink 
width and double tap are useful for tailoring the Vitalink to individual users. 
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4.10.14.5 Handwriting Settings 

The handwriting settings can be customized with this option. Each user can 
create a unique profile that allows a character dictionary to be built over time. 
This character dictionary will enable improved recognition in parts of Vitalink that 
use character input. In addition, a handwriting property can be set here to 
enable recognition patterns for right and left handed writers. 
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4.10.14.6 Color Settings 

Color settings can be optimized by individual users. Even though the Vitalink 
application may be operating only on a black and white screen, these changes 
can improve visibility for different lighting conditions. 



Color Schemes " 




4.10.14.7 Printer Settings 

Printer settings can be modified using this configuration option. 



'Default Printer 

HP LaserJet HlSi PostScript on LPT 1: 



Installed Printers: ' 



HP LaserJet IIISi PostScript on LPI1 



HP LesarJet Series H on LPT2: 

PostScript (Hicrografx) on None 

Tek Phaser III PXi (TekColoi) on LPT1: 



I Use Print Manager 
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4. 10. 15 Additional Applications 

The Vitalink software will allow other applications to be accessed through the 
Window menu item. In the future, other software packages, for example a word 
processing application or other automated administrative forms, can be added to 
contribute to Vitalink. This screen illustrates how new applications are added. 







Description: 
Command Line: 
forking Directory: 
Shortcut Key: 




I 1 |^^iC*ncrf£i4 




None | |:-v : finW_-^ 
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4.10.16 Help 

Help will be available at all times in the Vitalink application by touching the 
various help icons. The user will be able to easily search on various help topics 
throughout the system. The Help function will be modeled after standard 
Windows help facilities. 
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5. TECHNICAL ARCHITECTURE 



5.1 Mobile Computers 

This section describes the technical components of Vitalink . The software and 
hardware requirements are based on proven hardware platforms and available 
software development tools. The Vitalink concept, design, and databases will be 
portable to all types of computer hardware that are compatible with the Intel 
386/486 processor and Microsoft Windows for Pen Computing. 

Vitalink is designed to run initially on the Fujitsu 325Point. The 325Point is a 
light-weight, hand held, pen-based computer. It is 8.7" x 11.7" x 1.16", 3 pounds, 
and uses a 386SL microprocessor. There are no external wires or attachments 
to restrict the user in any way. This type of portability is extremely helpful to 
mobile professionals that may not be able to remain stationary while collecting 
data. The Fujitsu 325Point specifications are included in the Appendix. 

It is important to reiterate that this application is designed to run on all pen-based 
computers that are designed to use the Microsoft Windows for Pen Computing 
interface. The Fujitsu product is just one example of the technology available. 
Listed below are some of the other pen-based platforms that AMS supports with 
the Vitalink software: 



Manufacturer 


Model 


NEC 


Ultralite VERSA (Pen-Based) 




VERSA Pad 


AST 


Convertible 386/486 




GRiDPAD si 


Toshiba 


T100X 



5.2 Host Workstation Components 

The host application will run on an MS-DOS or OS/2 workstation. UNOS will 
require at least one computer to act as the host workstation with the following 
minimum hardware and software requirements: 



Workstation 


Software 


Peripherals 


Hardware 




Intel 486/66 MHz 


MS-DOS 6.0 or OS/2 


HP LaserJet-compatible 


processor 




Printer 


16 MB RAM 


MS Windows for Pen 


14.4kbps Data Modem 


500MB hard drive 


MS Access 




3 1/2" floppy drive 






5 1/4" floppy drive 







5.3 Mobile Data Communications 

Today, many organizations need a communications system to extend their 
internal computer system to their mobile work force. This system must transmit 



30 



BfflB 



UNOS VITALINK BUSINESS SYSTEM CONCEPT 



information to the mobile user efficiently, accurately, quickly and reliably with a 
I minimum of human intervention. 

The primary objective of the mobile communications user is to send and receive 
messages and data from anywhere at anytime. Systems capable of doing this 
must be simple to operate. They must handle the receiving, routing, and store 
and forward message delivery, regardless of the recipient's location. A user 
should have to know only a recipient's address, not their location. 

There are two primary options for wide-area wireless data communications. 
Existing cellular systems can support fax and data transmission. These 
networks were designed primarily for voice transmission and are not optimized 
for data communications. Some regional carriers have begun reconfiguration of 
their cellular networks to support reliable, digital data communications. This new 
layer will be optimized for mobile data communications! United Parcel Service 
(UPS) is the largest user of cellular technology for data communications today. 

5.3.1 Cellular Data 

The reconfiguration of the nation's cellular networks to support digital data 
transmission makes cellular technology relevant for the UNOS Vitaiink 
application. We are incorporating cellular data communications in the prototype 
release scheduled for February, 1994. 

Cellular data communications is based on the asynchronous, or serial, 
connection protocols many are familiar with using direct connection or wired 
) modems to communicate. The difference is the modem is connected to a device 

that can communicate via cellular network. Many phone manufacturers offer 
phone models that have a data port and modem. 

The existing cellular networks are configured for voice communications. This 
presents some limitations for passing data over these networks. The primary 
weakness of cellular is the data integrity and error checking. A voice user of 
cellular doesn't blink an eye when the voice signal weakens or is lost altogether. 
However, a weak or lost connection in a data transaction is fatal. The error 
checking necessary to ensure a byte arrived correctly slows down data 
transmission. 

Most network providers (Regional Bells. Cellular One, Meritech, GTE. PacTel. 
etc.) are adding a digital layer to their existing cellular networks to support digital 
data communications. This will support massive data communications with the 
added integrity of error checking of the digital (1 or 0) signal. Cellular data 
networks with digital capability are in testing in some metropolitan areas already, 
and will be common by 1996. 



5.3.2 RAM Mobile Data 

RAM Mobile Data is the only provider of packet-switched, wireless data 
communication services committed solely to providing such services. 1 RAM is 
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not affiliated with any particular equipment vendor and is committed to providing 
its customers with the appropriate equipment, application software and 
connectivity tools at the best possible prices. RAM supports the development of 
specialized equipment and software based on the open MOBITEX protocol. 
RAM is the only company to offer a proven, nationwide system that offers all the 
features demanded in today's wireless marketplace. These features are 
essential to support a full array of horizontal and vertical market applications. 
These features are: 

Wide coverage 
k Seamless roaming 

Store and forward capability 

.. Excellent response times 

.. Virtually unlimited capacity 

To operate on the RAM MOBITEX networks, RAM customers need radio 
modems and terminals designed to operate with a MOBITEX system. RAM 
provides documented open interfaces that enable development of custom 
application software and system integration services. Radio modems and 
terminal equipment are available directly from manufacturers to RAM customers. 
RAM ensures system compatibility by testing and certifying all products for use 
on its networks. 

5.3.3 Packet Switching 

Packet switching offers the most efficient way to transfer data. In packet 
switching, no end-to-end network connection is established. Instead, a packet of 
data is transferred between nodes until it reaches its final destination (the 
previously used facility is now free to handle another packet). In circuit 
switching, an end-to-end network connection must be established before data 
transfer can start. This method ties up the entire circuit, and no other data can 
be sent until the first transmission is completed. The radio path and other 
facilities may not be used even during idle time between user messages. Most 
voice messaging carried out between offices and mobile units can easily be 
replaced by packet data messaging. 

5.3.4 MOBITEX 

MOBITEX is a trunked. terrestrial, mobile radio system for packet-switched data 
traffic used for a variety of applications. The original concept for MOBITEX 
mobile radio communications was the design of a mobile alarm system used by 
field personnel of Swedish Telecom Radio. Because the concept was not 
economically feasible as a private network, it evolved into a public mobile radio 
service, which became MOBITEX. 

Early development of the MOBITEX network was carried out by Swedish 
Telecom. Continuing development is being carried out by Eritel, a joint venture 
Swedish Telecom and L.M. Ericsson. Ericsson is a manufacturer of MOBITEX 
network and mobile equipment. MOBITEX was first placed into commercial 
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operation in Sweden in the fall of 1986. Networks have since been constructed 
in Norway, Finland, the United States , the UK, the Netherlands and Canada. 
Additional MOBITEX networks are currently being installed in France and 
Australia, and many others are planned. 

Current MOBITEX systems comprise radio base stations, local switches, 
regional switches, and a network control center. They are trunked radio 
systems, meaning the radio channels are a common resource shared by all the 
users. Unlike trunked radio systems, traditional private radio systems have 
dedicated radio channels. 

MOBITEX subscribers communicate with others individually or as groups. 
Communication is also possible between MOBITEX subscribers and other 
external networks connected to the MOBITEX system. 

RAM Mobile Data selected MOBITEX for its mobile data communications 
networks because of MOBITEX's proven efficiency, reliability and flexibility to 
meet the many requirements of individual business and government users. 
MOBITEX is a worldwide standard for packet switched wireless data 
communications. 

Worldwide standardization of all MOBITEX networks and the compatibility of 
future development of advanced network features and functions are ensured by 
the MOBITEX Operator's Association (MOA). MOA is an independent 
organization of all network operators who offer wireless data service using the 
MOBITEX standards. 

5.3.5 Non-proprietary 

Descriptions of the MOBITEX operating protocols for radio modem hardware and 
software are open and available, without license fees, to any vendor planning to 
produce MOBITEX compatible equipment and applications. Copies of the 
MOBITEX Interface Specification (MIS), which details the open protocols, are 
available from RAM at a nominal cost. 

The RAM MOBITEX system support many open interfaces such as TCP/IP, LU2, 
X.25, POS and AT. Other interfaces will be added to meet market demands. 

5.3.6 RAM'S MOBITEX System 

RAM has operating licenses for its US MOBITEX networks in more than 200 
markets, including MSAs (Metropolitan Statistical Areas) and RSAs (Rural 
Statistical Areas). RAM's system now services over 6000 cities and towns in the 
US, covering over 90% of the urban business population. Additional coverage 
will be added in the future. RAM also provides MOBITEX service for the UK. 

5.3.7 Canada 

Cantel is operating a MOBITEX network in Canada in the same radio frequency 
band as that used by the US. Customers can connect to either system, using 
the same radio modem, provided they have subscriptions on both. This is called 
cross-border roaming. 
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5.3.8 RAM Network Features 

MOB I TEX networks incorporate a number 
networks from other mobile data networks 
summary of these features, along with the 

t Trunked radio frequency design 
and channelization 



Intelligent base stations and 
automatic Registration 



High data rate, low overhead 



Greater depth and breadth of 
coverage 



Non-proprietary over-the-air 
protocol 



Data-only, packet-switched 
networks 



Personal subscriptions 



Expert network operations and 
maintenance 



of key features that distinguish RAM 
. The following table shows a 
benefits to RAM's customers. 

High capacity 

Immediate channel availability 

Long-term growth without 
congestion 

High reliability and efficiency 

Smoother outbound messaging 

Automatic roaming 

Higher capacity 

Greater throughput 

Quicker response times 

More sophisticated applications 

More applications for hand-held 
terminals 

Local, regional, national and 
international applications 

Volume equipment purchase 

Single-source service provider 

Competitive bidding among 
vendors 

Customized hardware and 
software 

Reliability 

Security 

Cost effectiveness 
Security 

Personal identification 

Around the clock network 
monitoring 



5.3.9 Subscription Types 

A subscription is required for anyone communicating on RAM's MOBITEX 
system. Subscription types vary and are based on the system services chosen 
and on where and how the customer wants to use the network. 
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RAM's MOBITEX system offers the following subscription types: 
■> Host Terminal subscription 

* Mobile subscription 
Personal subscription 

* Group subscription 

Various system services can be linked to each of these subscription types. 

Access security can be implemented through the use of personal subscriptions 
with password protection, and through closed user groups that limit 
communications to a specified list of subscriptions. Additional levels of security 
can be provided in a subscriber's application. 

Subscription information and services are stored in network nodes and the 
terminal itself. This information is divided into two types: fixed and variable. 
The fixed subscription information is stored in the network and includes: 

* The definition of subscription and services 

* Subscription type 

* Subscription number 

* Group numbers 
Password 

. ESN 

^ Technical data about terminal equipment 
Radio frequencies 
Terminal type 

The subscription information is registered in the NCC when a new subscription is 
ordered by the customer or a subscription is changed. 

Variable subscription information is stored in all the network nodes and includes: 

* Roaming information for traffic routing 

* Message sequence numbers 
. Subscriber status 

* Active personal subscriptions 

5.3.9.1 Host Terminal Subscription 

A host terminal subscription is always linked to a particular terminal (generally a 
PC or host) connected to RAM's MOBITEX system through an FEP to a local 
switch. 

Host access to the system is usually provided by FEPs connected to the system 
at the local switch level. In addition, the FEP supports protocol conversion. 
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Currently supported is a datagram-to-session gateway for X.25 and SNA/3270, 
and a datagram-to-datagram gateway for TCP/IP. 

5.3.9.2 Mobile Subscription 

A mobile subscription is always linked to a particular radio modem. Radio 
modems communicate with the RAM MOBITEX system through radio links to the 
base stations. 

Any type of peripheral equipment (e.g., PCs, printers or simple terminals) can be 
connected to a radio modem through RS232 or specialized interfaces. Radio 
modems can be integrated with portable terminals and PCs, as well as terminal 
equipment designed for installation in vehicles. 

5.3.9.3 Personal Subscriptions 

A personal subscription is linked to a person and not to a particular terminal. It 
can be activated from any host, portable or mobile terminal that supports 
personal subscriptions. This flexibility is useful for customers who often use 
terminals located in more than one location. 

Any system services defined in a personal subscription are available when the 
user logs onto the network. However, the technical limitations of the terminal 
being used can limit their services. 

A login message sent from the terminal includes a password. It also notifies the 
MOBITEX system that a personal subscription is being logged in and the 
address of the terminal being used. The MOBITEX system considers the 
subscription transferred to this terminal until the user sends a logout message or 
logs in at another terminal. A personal subscription can only be logged in on one 
terminal at a time. A terminal can have up to seven personal subscriptions 
logged in simultaneously. 

A password is mandatory for personal subscriptions, and protects the subscriber 
from unauthorized use. To increase the level of security, the subscriber can 
request the network operator to change the password at the NCC. 

5.3.9.4 Group Subscriptions 

A group subscription comprises a number of mobile and host terminal 
subscriptions. Each mobile or host subscription can be a member of up to 15 
different groups. The members of a group are addressed by the subscription 
number of the group. A group subscription only receives messages. 

This service minimizes the work of dispatch personnel by sending identical 
messages to numerous subscriptions. A group message is sent to terminals in a 
limited geographical area, selected by the customer. This area is defined by a 
selected set of base stations together with the host terminals for the group. The 
base stations and host terminals are designated as search nodes. 
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There is no definite acknowledgment from each recipient of a group message 
Any unit that is out of radio range, shadowed or switched off will not receive the 
message. However, the network will broadcast a group message several times. 
The group subscription information contains a definition of: 

«. Mobile terminal subscriptions 

«. Search area 

.. Traffic type (data, text or status) 
5.3.10 Messaging Services 

Messages delivered through the RAM MOBITEX system are sent MPAKs An 
MPAK contains from one to 512 bytes of user information. A 1-byte message is 
called a status message. Longer messages, containing up to 512 bytes of user 
information, are sent in ASCII text format or as data coded in any application- 
dependent format. The maximum size of a text message is 545 bytes (512 bytes 
of user data and 33 bytes of network data). 

Sets of 256 numerically encoded status message codes allow many standard 
messages to be sent quickly and economically through the system. 

More complex digital information is sent as 

- Data 

. Higher Protocol Data (HP Data are sub-messages of messages 
longer than 512 bytes) 

The following table shows the types of services available to subscribers on the 
RAM MOBITEX system. 



Services 


Mobile 


Fixed 


Personal 


Group 


Text/Data/HP Data 


</ 








Status 










Password 










Group Messages 










Store and Forward 


V 









5.3.10.1 Text Messages 

Text messages consist of MPAK header information and user-supplied data 
coded according to international ASCII standards. The maximum size of the 
user data in a text message is 512 characters (bytes). 
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5.3.10.2 Data Messages 

Data messages consist of MPAK header information and user-supplied data 
Data messages are used instead of text messages when information is 
transferred in formats other than ASCII. In contrast to text messages user data 
can be freely coded by the individual terminal application. The maximum size of 
the user data is 512 bytes. 



5.3.10.3 HP Data 

HP Data (Higher Protocol Data) is used for messages that exceed the maximum 
size (512 bytes) and indicates that the contents of the associated packet require 
special processing. In the transport layer (included in the user application), the 
onginal message is disassembled into several sub-messages (multiple MPAKs) 
These sub-messages are then transmitted as HP Data messages by the network 
layer. 

The receiving terminal's transport layer protocol reassembles the sub-messages 
into the original complete message. The order in which the different sub- 
messages are transferred to the receiving terminal is not controlled bv the 
MOBITEX system. ' 

HP Data messages are divided as follows: 
.. MPAK Header information 
- Type of protocol used in the transport layer 
.. Transferred user information 



5.3.10.4 Store and Forward 

A store-and-forward capability is available for subscribers who are temporarily 
out of contact with the system when messages are sent to them. 

If the addressee of a MOBITEX message cannot be reached the message is 
temporarily stored in the system. A copy of the message, and an 
acknowledgment indicating that the message has been stored in an electronic 
store-and-forward device, are returned to the sender. Before the message is 
sent, the sender may choose not to use the store-and-forward capability. 

When the addressee of a stored message re-establishes network contact and is 
registered, stored messages are sent. The addressee is informed that the 
messages received were stored in the electronic store-and-forward device. 

The store-and-forward device has capacity often messages per subscription. 
Once a mailbox is full, new messages are returned to the sender. Messages not 
retrieved within several hours are deleted. 



5.3.11 MOBITEX Functions 

The RAM MOBITEX system incorporates many unique functions to provide a 
seamless, transparent communications link for its customers. These functions 
also enable RAM to achieve its primary goals of: 
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* Maximizing radio path efficiency to ensure economical service 
^ Providing effective traffic routing 

- Providing a fast and reliable mobile data communications service 

* Making superior services available to all users, regardless of 
subscription type 

* Maximizing customer satisfaction 

Traffic congestion in most wireless communication systems occurs primarily in 
the radio link. One way to minimize traffic congestion is to reduce the number of 
packets transmitted through the base station. There are several ways to do this. 

First, the system makes no attempt to reach terminals out of network contact 
(i.e., equipment is switched off or out of radio coverage). The store and forward 
service is provided to handle these cases. 

When terminals are switched off, they notify the system by sending an inactive 
message. All the personal subscriptions registered on that terminal will also 
become inactive. 

When terminals are switched on, they automatically notify the system by sending 
an active message to the base station. The system maintains a log of active 
terminals and their locations. Host terminals send an active message 
immediately after being switched on. Mobile terminals can be set to delay the 
transmission of the active signal. Only if a mobile terminal is inactive within a set 
delay time of 30 to 60 seconds will an active message be automatically sent to 
the base station. The purpose of this delay is to avoid unnecessary traffic on the 
radio channels. 

If a mobile terminal loses radio contact with the system, it automatically sends an 
active message when radio contact is re-established (subject to the above 
mentioned delays). Messages that have been stored in the subscription's store- 
and-forward device are then sent to the mobile terminal. 

A second method that helps to reduce congestion makes use of a distribution list 
that enables a single message to be sent to a number of other subscribers. The 
sender includes the MANs of all the addressees when sending the message. 
The system copies and transfers the message to each of the addressees. A 
group broadcast message may also be sent to a number of subscribers sharing 
a single subscription number. 

To keep the transfer time for messages between subscribers as short as 
possible, all traffic is processed through a minimum number of system nodes. 
The hierarchical structure of the MOBITEX system, together with the storage of 
subscription information in the current system branch ensures efficient routing of 
messages. 

When a message is sent between two subscribers operating through the same 
base station, it will be processed by that base station only. In this case, the base 
station is designated as the turn-around node for the message. If subscribers 
are using two different base stations connected to the same local switch, the 
local switch is the turn around node for the message. If a regional switch is 
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involved in the traffic routing of a message, it is the turn around node for the 
message. 

5.3.11.1 Reliability 

To make communications more reliable, network nodes can function in 
autonomous operation if the connections to superior nodes are lost. 

When a base station is in autonomous operation, traffic between mobiles 
registered at that base station can continue. Likewise, if a local switch is in 
autonomous operation, all traffic between base stations connected to that local 
switch can continue. This method of operation guarantees that any temporary 
link failure in the system will have minimum impact on service. Dial-up modems 
can also establish temporary connections between nodes in case the main 
connection is lost. 

5.3.11.2 Roaming 

Roaming provides mobile radio modems (mobiles)with the ability to stay in 
constant communication with the system. Mobiles monitor and evaluate system 
channels from surrounding base stations. An algorithm built into the radio 
modem determines if and when transfer to another base station is necessary. 

When a mobile terminal moves to a new base station, it sends a signal to the 
new base station to inform the system that all subsequent traffic to this mobile 
terminal should now be routed through the new base station. Subscription 
information stored in the old base station is forwarded to the new base station 
and other nodes within the new network branch. Current system channel and 
current base information, stored in the radio modem's memory, is updated when 
the radio modem is powered off. 

5.3.12 System Performance and Reliability 

Performance of the system can be measured in terms of the time it takes to 
transfer a message between a mobile radio unit and an attached host (or 
another mobile) anywhere in the system. 

This measure is dependent on the system configuration, including radio channel 
parameters and the following; 

* Message length distribution 

* Baud rate of internode links 
Node processing time 

- Number of nodes involved 

- Overall traffic load 

Average one-way message transfer time through the RAM MOBITEX system 
ranges from two to five seconds, depending mostly on message length and the 
number of nodes involved. At least 90 percent of all messages to active 
subscribers in good radio contact are delivered within ten seconds. 



40 



ams 



UNOS VITALINK BUSINESS SYSTEM CONCEPT 



The design of MOBITEX includes very few components that can fail and cause a 
total system failure. For example, the loss of a radio channel in a base station 
would only be evident as a reduction in the service level for the base. 

All communication links between nodes in the RAM MOBITEX system are 
backed up to rapidly restore service in the event of failure, and all 
communications equipment is centrally monitored as part of RAM's MOBITEX 
network management system. If the connection between two network nodes is 
lost, the node on the lower level will go into autonomous operation, and the next 
higher node will send an alarm to the Network Control Center (NCC) reporting 
this event. 

The RAM MOBITEX system includes spare local switches for scheduled 
maintenance and for backup in case of a node failure. 

Long-distance providers (LDPs) likewise have spare switches to minimize any 
loss of cross-region traffic should a switch fail. Also, customers may elect to 
connect their hosts directly to multiple local switches (where traffic patterns 
warrant) to obtain additional redundancy in their overall network solution. 
Temporary base station failures are generally not serious because of area 
containment and the overlap by adjacent base stations. 

RAM Mobile Data's objective is to maintain an overall system availability of 
99.9% or better. To achieve this, RAM will ensure the following: 

Base Stations 

* 90 percent will be repaired in four hours or less 
Traffic-affecting alarms will be: 

* Escalated to a field engineer immediately 

* Escalated to the director in four hours 

* Escalated to the network vice president in eight hours 
Switches 

* 90 percent will be repaired in two hours or less 

* Traffic-affecting alarms will be: 

Escalated to a field engineer immediately 

Escalated to the director in one hour 

Escalated to the network vice president in two hours 
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6. PROJECTED COST 



This section lists the estimated hardware, software and communications costs 
for implementing the full Vitalink application. Additional development costs for 
the custom Vitalink application are not included here. 

Host Costs 

Host workstation computer: $4,500 

(including radio modem) 

Connectivity $ 1 00 per month 

Per User Costs for RAM Implementation 

Mobile computer: $2,000 

Radio Modem $775 

Service Charge $25 per month 

Transaction Cost $0,125 Cents per 512 characters 

Average transaction size 1024 (min.) - 10,240 (max.) 

Average transaction cost $0.25 - $2.50 
Per User Costs for Cellular Data 
Mobile Computer $2,000 
Cellular Phone & Modem $800 
Monthly Service Charge $13.95 

Transaction Cost $2.00 - $5.00 avg. per transaction (projected) 
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7. SCHEDULE 



7.1 Prototype Development 

This section describes the system development plan and the prototype release 
schedule. The Vitalink system development plan is based on AMS's Rapid 
Development Methodology. This methodology is a subset of AMS's Lifecycle 
Productivity System (LPS), which is a set of corporate-wide tools and standards 
for developing quality software. 

User Interface, Application Functions and General System Design 

In this phase, the AOPO form will be broken out into a comprehensive yet easy 
to use interface. The functions of the system will be dictated by the amount and 
types of information uncovered during this phase. A general system design for 
the wireless communication process will also be outline during this phase. 

MILESTONE DATE: December 20, 1993 

Vitalink Initial Prototype Release 0.1a 

The initial release of the Vitalink prototype is intended to provide UNOS and the 
pilot Organ Procurement Coordinators an introduction to pen-based computing 
and help them understand the user interface. Advanced features are not 
supported and communications are not included in this release. 

MILESTONE DATE: January 5, 1994 

Vitalink Prototype Release 1.0 

This release of the Vitalink prototype will include identified enhancements to the 
user interface and the wireless communications. This release will be used for 
the prototype test at the chosen test sites. 

MILESTONE DATE: January 31, 1994 

7.2 Prototype Feedback 

This phase will monitor the operational test sites and gather feedback data to 
develop a proof-of-concept document. The analysis results from this stage will 
be used to develop the production version of Vitalink. This phase has not yet 
been tasked. 

DATE: February- April, 1994 

7.3 Production Development 

A plan for production development and implementation will be developed based 
on the results of the feedback from the Vitalink prototype. User interface 
enhancements, communications, and back-up methods will be tuned and 
polished for a production version of Vitalink to be released. This phase has not 
yet been tasked. 

DATE: July, 1994 
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1. INTRODUCTION 



The purpose of this document is to set expectations and requirements for the 
participants of the Vitalink pilot. The purpose of a Pilot Evaluation is explained 
as well as the basic functionality of the Vitalink system. 

The goal of the Vitalink prototype is to accomplish the implementation of baseline 
functionality first, and add on more sophisticated functionality when feedback 
from the users can be analyzed and evaluated. This type of iterative design and 
development process is proven to be very effective in creating an accurate 
design and developing a better overall system. 
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2. BACKGROUND 

Vitalink is a data collection tool designed for the unique requirements of the 

ha^he d a To 9 m n°T mUnity , ? " aPP ' iCati0n ^w^pen-oased. 
Ornt P n P e : S . and W,releSS d3ta com ™nications. Vitalink supports 
Organ Procurement Coordinators in the field to collect and transmit the essential 

IxZlT 1 "* 0 " t0 the UN ° S ° r9an Center so that a ™** run can be 
executed on the existing system at UNOS. Vitalink provides a mechanism to 
s andard.ze the data collected about donors to increase the chance ofTrgan 
placement. Vitalink allows the coordinators to collect the donor data wherever 
and whenever the information becomes available. wnerever 

Vitalink automates the data on the Association of Organ Procurement 
Organ.zat.on s (AOPO) form. The appendix illustrates how the AOPO form was 
broken out for the Vitalink system. The user interface for the mobile port on of 
Walmk was delivered on January 10. 1994. The wireless communications Z 
be incorporated by the end of March for prototype delivery. Full-scale 

pTo'otyp'e" resufe 5 P ' anned *" " ' 3 th ° r ° U9h review of the 

Originally established in 1977 by members of the South-Eastern Organ 
^M C ^ ment Foundation (SEOPF). the United Network for Organ Sharing 
optm^ ° P ! r f 65 "f 0031 ° rQan Procurem ent and Transplantation Network 
7X d ' he nat,onal Scientific Registry for Organ Transplantation. In this 
role, UNOS functions as a contractor for the federal government and a private 
non-profit corporation. Under contract with Health Resources and Services ' 
Administration (HRSA). UNOS has operated the OPTN since September 30 
1 986, and the Scientific Registry since September 30, 1 987. 

American Management Systems, Inc. (AMS) is the developer of the Vitalink 
Application software in partnership with UNOS. AMS is based in Fairfax 
Virginia. Founded in 1970. AMS specializes in helping clients improve their 
performance through the intelligent use of information technology AMS 
combines specific industry experience, business function expertise proven 
systems development practices, and an extraordinary depth of technological 
competence to help our clients meet their business goals 
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3. VITALINK LIFECYCLE 



The successful use of any resource occurs through a lifecycle beginning with 
requirements identification and ending with disposal. Traditionally, information 
technology solutions are developed using a lifecycle approach beginning with a 
requirements study that results in the design, development, maintenance and 
ultimate disposal of an information system. Disposal usually is preceded by a 
new lifecycle for the application's replacement. 

Many information technology applications, like accounting, payroll and inventory 
systems, are known well enough to be implemented using a traditional approach. 
Often, the core functions of these types of systems are assessed using a binary 
measurement - either they work or they do not. The traditional lifecycle is best 
suited to stable, institutionalized processes. 

On the other hand, advanced technology applications can be very costly and fall 
short of their functional goals when using a traditional approach. An iterative and 
practical approach is more appropriate for mission-critical advanced technology 
projects. The iterative approach uses a series of development cycles - design, 
develop, test - to achieve functional goals. Each iteration serves as a checkpoint 
to measure progress and solve application problems. 

3.1 A Risk-Based View 

A risk-based view of the enterprise solution is effective for developing an iterative 
development plan. The iterative plan addresses each risk area and identifies the 
factors or approaches that mitigate the risks or minimize the adverse impact of 
problems stemming from a risk. 

Risk is the likelihood of injury or harm. A practical measurement of risk is the 
probability times the severity of something occurring. The risks typically 
encountered in an advanced information technology application are listed below. 

3.1.1 Concept Risk 

Acceptance and Continued use 

Concept risk can encompass aspects of all of the risk areas below. Problems at 
the concept level will reduce system acceptance and continued use. New 
processes, technologies, users and design principles affect the feasibility of the 
solution concept and its long-term success. 

3.12 Economic Risk 

Potential for other outcomes: 
Revenue, direct or indirect savings, and support-cost projections 
Financial planning for a technology solution includes estimating lifecycle costs 
and benefits of a system during its lifecycle. Economic risks are the factors that 
cause the project to fall short of revenue, savings or support-cost projections. 
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Iterative prototyping helps alleviate economic risks by enabling the development 
of accurate financial models based on each application release. These models 
j . czn be more accurate each time as the sample increases and the quality of the 

application improved. 

Support is usually the most costly part of the system lifecycle. Emphasis on a 
well-conceived support plan will prepare the organization for economic risks. 

3.1.3 Technology Risk 

New or Unproven for use, users, volumes and performance requirements 

Technology risks grow when there is a mismatch between the requirements and 
the technology specifications and performance. Technology planning based on 
high-medium-low expectation scenarios of the system's performance can avoid 
problems in this area. The significant difference between development, 
prototyping and production is the amount of user demand on the system. Each 
component of the system should be designed to support maximum loads 
independent of other components. 

These factors include handwriting recognition accuracy of pen computers, 
durability of field devices, battery life and communications. For example, poor 
communications throughput puts additional demand on system battery and 
ultimately affects overall system performance. 

3.1.4 Implementation Risk 

) Software design, project management, integration and delivery 

Implementation problems affect long-term project success through missed 
deadlines and component integration problems. Key problem areas during 
implementation are access to reliable development resources, project planning, 
component integration and component obsolescence. 

3.1.5 Organizational Risk 

Traditions, norms, processes, culture, new skills 

Organizational factors are the most challenging to solve in an information 
technology application. They are at the heart of the organization and they 
represent how the organization executes its mission. Changes in these areas 
can result in complex cause and effect reactions that are difficult to solve or 
mitigate. 

Organizational risks usually range from inadequate developer skills, lack of 
management support, process redesign and low user acceptance. A change 
management plan that accounts for these organizational areas is effective for 
managing this area. 
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3.2 Project Phases 

Winter 1994 ' Spring 1994 Summer 1994 



Fall 1994 



Business System : Prototype , , . ~ . — > 

Concept | Development i Evaluation ; Development ' ""Phnwnlrton 



^ s ■ , .-s; 



J Production Design 

V •-. I .- .... ... 



Support 



The Vitalink application is being developed using a phased approach Seven 
overlapping phases are planned during the lifecycle of this system. Some tasks 
from these phases may be repeated to enhance the accuracy of the Vitalink 
design. The phase which is discussed in this document is the Pilot Evaluation. 

3.3 Why conduct a pilot evaluation? 

The Vitalink Pilot Phase is one phase in the application's lifecycle. Feedback is 
gathered dunng the pilot phase on the application's performance in each of the 
risk areas described above. The key is to find the success factors that justify 
continuing with the project, while solving and managing problem areas that affect 
progress. However, focusing on risk areas can be too reactive when building a 
long-term technology vision for Vitalink. 

The key to the successful pilot evaluation is the measurement of the important 
attributes of the Vitalink application within the risk and business, technology 
factors structure. This will help to establish the plan for continuing. Many of 
these answers are known today. For example, wireless communications are 
consistent with UNOS strategy and systems architecture. A detailed Vitalink 
evaluation plan is developed in the next phase to support feedback gathering 
and future planning efforts. 
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4. PLAN FOR EVALUATION 



4.1 Surveys 

Both phone and mail surveys will be used throughout the life of the pilot in order 
to evaluated Vitalink's performance and usability. Participants in the pilot should 
expect phone calls at least one every two weeks to determine the progress of 
the system evaluation. 

4.2 Site Visits 

Follow-up site visits will occur at least once during the prototype. A simulation of 
the use of Vitalink and a group discussion between the coordinators will be used 
to collect information about the Vitalink system. 

4.3 Telephone Support 

The technical support phone line will be available to all users of the Vitalink 
system. Users can call to report problems, ask questions or even to give 
suggestions and ideas for improvements to the system. 
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5. CONSENT FOR PARTICIPATION 



As a participant in the operational testing of Vitalink, you agree to provide to 
UNOS feedback on a regular basis on the performance of the Vitalink system. 
This pre-production version of Vitalink is not meant to replace the current donor 
information collection process. Instead, it is to be used in conjunction with the 
current process to identify the benefits and/or short comings of the Vitalink 
application. The input which you provide will be folded back into the production 
system development in order to make a donor information management tool 
which can be used effectively by every Organ Procurement Coordinator in the 
field. ■ 

The Vitalink software has been developed to target approximately 80% of the 
total functionality. It is through the feedback from the pilot participants that the 
remaining essential 20% functionality be uncovered. Yoii can also expect that 
there will be program "bugs" or errors in the Vitalink system. Uncovering these 
problems is another function of pilot paridpatioh. 

By signing below, I agree to the following: 

1 . I will not load any other software on the hardware which is provided 
specifically for the Vitalink operational test. 

2. I will report any technical or functional problerns encountered with the Vitalink 
--■ software as soon as possible. 

3. I wiH ask questions as they arise about the application of functions in the 
Vitalink system. / / 

4. I will respond to UNOS sponsored phone and mail surveys on a timely basis 
concerning the performance and evaluation of the Vitalink system. 



Signature Date 



Print Name 



Organization Name 



s 
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6. HARDWARE 



There are two types of hardware platforms being evaluated during the pilot 
They^are the Fujitsu 325Point pen-based tablet and the Compaq Concerto pen- 
based notebook. The Compaq is being demonstrated, but not supplied for the 



Machine 


Processor 


Hard Drive 


PCMCIA 


3.5" drive 


Keyboard 


325Point 


386/25 


42MB 
removable 


1 Type II 
1 Type III 






Compaq 
Concerto 


486/25 


120MB fixed ! 


2 Type II 







Each test site will also have a one Mobidem radio modem and one Lexmark/IBM 
portable printer. The radio modem only needs to be attached when sending data 
to UNOS. The printer only needs to be attached when printing the AOPO 
Vitalink report. 



! 
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8. APPLICATION WORKSPACE 



The Vitalink system is designed to be consistent with all standard Windows 
software. The illustration below show a sample of the Vitalink application 
workspace. 




Each part of the illustration above is explained in the following sections. 
8.1 Main Menu 

| £ase Options System Window tjelpT] 

Each major function in Vitalink can be launched from the toolbar or the main 
menu This is consistent with most Windows products. Touch the desired menu 
with the pen to access the menu choices. 
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8.1.1 Case Menu 



Case Options System Window Help I 


Close 
Delete 




Print 
Send 
Export 


Exit 



The actions listed above can be executed once a case is opened or created 
The Case Menu controls specific functions concerning the current case From 
the Case Menu cases are created, opened, closed, deleted, printed, exported or 
sent to UNOS. Each of the options are discussed in more detail later in this 
document. 



8.1.2 Options Menu 



| Case Options System Window Help 




On Screen Keyboard 
Popup boxed edit fields 
On top boxed edit fields 





The Options Menu allows the user to choose how to enter data when using the 
pen. No options should be selected if data entry is being performed via the 
attached keyboard. All of the edit boxes are illustrated in the Data Entry section. 

On Screen Keyboard 

Select the On Screen Keyboard option to have the soft QWERTY keyboard 
appear on top of the Vitalink application. This assists in data entry while using 
the pen. A check appears next to the name on the menu when this option is 
selected. 



Popup Boxed Edit Fields 

The Popup boxed edit fields option allows the user to write data with the pen in 
an expanded text box for easier character recognition. Each time the user 
touches a field when this option is selected, an edit box will appear to accept the 
written data. When a new case is created, this option is automatically selected 
A check appears next to the name on the menu when this option is selected. 

On Top Boxed Edit Fields 

The On top boxed edit fields performs the same basic function as the regular 
popup boxed edit fields except that it always appears on top of the form and can 
be moved around by the user. A check appears next to the name on the menu 
when this option is selected. 
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8.1.3 System Menu 

| Case Options System Window Help 
Configure Pen 
Calibrate Pen 
Configure Handwriting 
Handwriting Trainer 
Set Date and Time 
Color Settings 
Printer Settings 

The System Menu sets options specifically concerning system settings which 
affect Vitalink's look and feeL Each of the following options have on-line help 
available for a more in-depth discussion and assistance. 

Configure Pen 

The user can configure the settings for the pen with this option. Settings like ink 
width and double tap are useful for tailoring the Vitalink to individual users. 

"Pen DouWe-Up J 

" Double-tap &iea 1 

S»afl Large 

~0oub4e-t*p Speed j 

SUm Fax) 

TEST I 



~Eiet« ant 
Short 


I Hold 1m 


e Delay 
Long 




Jtf witting and selecting here: 




M 


U 


: H 




Sanple Text 














I « 




Cancaf 


I 





Calibrate Pen 

Occasionally the pointer on the screen becomes out of sync with where the pen 
is actually pointing. The calibrate pen function makes the user touch the cross 
point of two lines on various points of the screen. This should correct any 
pointing errors that may be occurring. 




Calibrate 



ren irw 
~ Ink Width 

ID 



Sample " 



" Ink £ofcw ' 



□□□HI 



Configure Handwriting 

The handwriting settings can be customized with this option. Each user can 
create a unique profile that allows a character dictionary to be built over time. 
This character dictionary will enable improved recognition in parts of Vitalink that 
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use character input. In addition, a handwriting property can be set here to 
enable recognition patterns for right and left handed writers. 



Handwriting 







wnung nana 


4 





'Menu Style' 



111 1 



Recognise — 

□ When gen u lifted 

Short Long 



OK 



Handwriting Trainer 

The handwriting training utility is a very useful tool to improve the overall 
character recognition of handwriting throughout the system. It is recommended 
that every user experiment with this function to become more familiar with the 
fundamentals of pen computing. 





Trainer 




When lent is twsrecognized. it will be the 
below. 












- I 
Advanced | 







Set Date and Time 

Occasionally the system date is incorrect when the battery runs down to 
extremely low levels. Use this function to correct the date and time. 







| Q/24/94 $ 






rhmc ; 

[ 3:37:gi]PM|H 


|;£|Wp 1 
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Color Settings 

Color settings can be optimized by individual users. Even though the Vitalink 
appl.cat.on may be operating only on a black and white screen, these changes 
can improve visibility for different lighting conditions 





I—2LJ |_g*?_J 



Printer Settings 

Printer settings can be modified using this configuration option. 





Printers | 


rOefauft Print d — 

| HP L«ic*Jet 4Si/4Si MX on LPT 1: 




pirutalled P_rintem: " 

Genigraphict* Olivet on GENI 






1 ttonrmcLl J 


n " ■ i ii ■ ■■ ■■■■ — 

HP LdtmJet HP on LPT1: 






| Stf As DW«* Pmtar | 




1 A*f» 1 


S U«« Prim M«nag« 


1' 1 



5.14 Window Menu 



1 Case Options System 


Window Help | 




lile 




Cascade 




Close All Forms 




VI Vitalink Forms 




2 Consent and Admission Data 




3 Chemistry 




4 Urinalysis 



The Window Menu is used to manage your application workspace. The Tile and 
Cascade options allow the user to see all open forms in an organized manner 
The Close All Forms option clears the application workspace of all open forms by 
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saving data and closing down each window. The Vitalink Form list window does 
not close while a case is still open. 



8.1.5 Help Menu 

£ase 



Options System Window jjelp"*] 

There is no on-line help during the testing phase of Vitalink. The production on- 
me help will be similar to other Windows applications* on-line help. Vitalink's on- 
line help will closely following the User Manual which will accompany each 
licensed version of Vitalink. 



8.2 Main Toolbar 



G3EIUII 






Hi 


iii 



Vitalink's main toolbar has an icon to represent each major function of the 
system. All of the functions available on the toolbar are also available throuqh 
the menus. 



8.2.1 New 



The blank sheet of paper represents a new case. Press this icon when opening 
a new donor case. 



8.2.2 Open 



IS 

The open folder represents opening a case which already exists. Press this icon 
to get the following window: 



Open Case 



Oonot Hi 



jOPO Cw Wuabw jRecovaryPate 



fcathy Peaetti r " : 4QQ45300171 



2/1/34 



j 00456733001 



12/3J3*: 




QK 



Caned 



SortOrdet 




:- ^OanorMnw - 


'I 


CPOC«»i 


I 


• : TWOOWI 0** | 




f 


UNDSOi 


1 


J Donor Ho^t*| | 


• : '.M»Wfl«i;.| 



The Open Case windows allows the user to choose which order to view case 
information. To change the sort order, touch the name of the field which you 
want to sort on and drag it to the desired sorting position. This option gives the 
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^ni nat0rS 9reater flexibility in creatin 9 a cu stomized interface. The sort order 
for opening a case can be changed at any time. 

JnuTn* CaS6 ' d ° Ub,e tap ° n the desired case ' or touch case and then 



touch OK. 
8.2.3 Close 



rcas?r s e co f ltL r w P re T tS d0Sing 30 active Mse - Touch the dose icon when 
a case is completed, or if you want edit or create a new case. 

8.2.4 Delete 

OB 

dP^h 1 ! 030 re P fesents the delete function - Touch this icon when you want to 
delete the current case. 

8.2.5 Print 

m 



The printer represents the printing utility. Touch this icon when you are ready to 

SThTil nt ; re h A ° PC i f °J m c DUrin9 the initial teStin 9 P hase - on, y the ^tire report 
will be able to be printed. Eventually, different sections of the form will be able to 
be printed separately. 

M^l a rt k ft e r V ! ral T,T! eS t0 print the entire A0P0 Vitalink form - Vitalink calls 
Microsoft Word for Windows to perform the reporting function and display the 
report on screen. Touch the print icon in Word to print to the printer. Exit Word 

Vitalink F " e ' EXit menU ° Pt ' 0n ' Th ' S W '" retUm thS pr °9 ram contro1 10 

8.2.6 Send Data 



The satellite dish represents the radio communication function of the Vitalink 
system Touch this icon when you want to wirelessly send the data you have 
conect for a donor case to UNOS. The case does not need to be completely 
filled in order to send it to UNOS. Each time the case is sent to UNOS the 
previous version is overwritten and the latest changes are saved. 

The Vitalink communication process notifies the user as to the status of the file 
which ,s being sent to UNOS through message boxes. Depending on the size of 
the file, ,t may take several minutes for all of the data to be transferred once the 
satellite icon is touched. 
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8.2.7 Export 

a 

The right arrow represents the export utility. This function initially will not be 
available during the pilot. 

8.2.8 Field History 




The binoculars represent the field history function in Vitalink. Every time data is 
entered into a field, a history is created for that field which can be used later. For 
example, XYZ Hospital is entered for a donor. Later on, with a new or edited 
case, the field history icon can be touched to reveal the list of hospitals 
previously entered. Now the user can touch on the name in the list instead of 
having to write it out again. 

8.2.9 Help 




The question mark represents the on-line help utility. On-line help is not 
available during the pilot. 

8.2.10 Exit 




The door represent the Vitalink system exit. Touching this icon will close the 
active case and exit Vitalink. 

8.3 Vitalink Forms List 



The Vitalink Forms list is based on 
the AOPO form which is then broken 
down into logical and manageable 
sections. The appendix at the end of 
this document illustrates how the 
AOPO form was broken up. This list 
is opened when you create or edit a 
donor case. Once a case is opened, 
the list serves as a guide to which 
sections have been visited. For 
example, the Case Information form 
is always the first form which opens 
when a case is created. In the 
accompanying diagram, a check 



I Vitalink Forms 


■w 




SW&G- I II IHIHIII 




Donor Information 




Content I Admission Information r 




Intta! Physical Arte nam J 




Assessment Diacvem I Comments 




Medcal/Socsel History 1-10 




: Medical/Social History 1 1-19 ^ 




iJSPHS €»«da i Respondent Date 




Chemistry - £ " .>■>/' 




- Uiiriajysss _~r - rV-i'-* 7 ' \ 




esc tiDtff 




Serology ^ ■> 1 - 




• Microfaibtooj* - : . 




HenooVnaatcs/Tempefah^e 
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mark has been placed next to the Case Information form name. This indicates 
that Case Information has already been opened. It does not necessarily mean 
that the section is entirely complete. 

8.3.1 Grouping Icons 



Since there are a large number of AOPO sections, the grouping icons will display 
only forms in specific areas. 



All Forms 

0 



The magnifying class icon 
represents the function to 
display all sections of the AOPO 
form. 



Vita I ink Forms 




Donor Information 



Content I Acmssston Information 



Initial Pjysjcaj Assessment 



A lign ment Diagram 4 Comment* 



Medical/Social History 1-10 



Medical/ Social Histo ry 11-19 



USPHS Criteria 4 Respondent Data 
Chemistry ,', . . • ~ - 



OriWysit 



C8C4DW 



: Serology-; 



Hcmo^ iwWri temperature 



Intake/Output 



tnfaopic Support 



Cardiac Data 



Pum>onary Date 



ArteriaJ Btood 6 
Mediations 



Infcraogeiative Management 



Kidney Data 



Left Kidne y Anatomy ■ 



Right Kidney Anatomy 



Heart Date 



Lung Data 



i D ata 



Uvet Data - 
Tissue Data 
Hotet : 
Diipojubon '"• 
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Patient Medical/Historical Forms 



The first aid cross icon represents 
the function to display only the 
sections of the AOPO form which 
have to do with general medical 
history or administrative forms. 



I Visa 



Vitalink Forms 




✓ Consent t AaWtdon Informatio n 
Initial I 



Al ignment Diagram * C n mm im U 
Meoicai/Social History MO 



Mwfcai/Sociai Hbtory 1M9 
USPHS Criteria 1 Ri 

Notei ••■wUfr-T'. £ 
. Dcspos£ion 



Data 



Laboratory Forms 



The beaker icon represents the 
function to display only the sections 
of the AOPO form which have to do 
with laboratory results or 
medications. 



Organ Forms 



The heart icon represent the 
function to display only the sections 
of the AOPO form which 
specifically contain organ data. 



r 

Vitalink Forms 



BE0C 



✓ Serology 



ature 



Intake/Output 



Jntaopjc Support 



Artmial Blood 6a 



Vita 



SEED 



Vitalink Forms 



C**acData 



Pulmonary Daja_ 



rKdWData 



LiMearUtaa 



lung Data 



Data 



livaf Data ^ 
_TnwueData 
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8.3.2 Launching a Form 

To open a form, double tap on the form name in the Vitalink Form ikt if un „ M „ 

5.3.3 Closing a Form 

rrr^. is aiso 5av * — y ° u *** * 

8.3.4 Minimizing a Form 

I^thf h3 V he ° Pti0n ° f minimi2in 9 forms instead of closing them This is iust 
the LI T*h man39e the d3ta entry process Minim ™9 a form gets it out of 

E~ •fc^^r* infor r ion in the form a fo- s 

Fnrm „ r „ k m ° f the screen b y an icon whic h matched the Vitalink 

Form group where .t can be found. To minimize a form touch the Tdown ZZ in 

on'thT' n9 l ha I d COmer ° f the form - To restore a ^etlTSoJZZ 
Restore ° f Saeen ° f t0UCh the icon once and ^ 

8.4 Data Entry 

cTnte ufJd nnLT ?"' eS ° n Vari ° US meanS t0 9ather donor information. Vitalink 
can be used on a laptop or on a pen-based computer. This means that the user 
can set various opt.ons to enhance the speed of data entry. 

8.4.1 Using the Keyboard 

IteZnT" iS h f '" in9 ° Ut d0n ° r information a t a desk or some other station 
site then he or she may want to use the keyboard for quick data entry The Den 

con? ' 3Se ' S t USed 3 ! POintin9 device ' like a mouse - the pen to select 
.cons, menu items or to open and close forms. Use the keyboard to type in the 
donor mforma tion. The Tab key is used to go from field to field. Using the Alt 
^^Z^' ^ * - "* -u wi„ gairfaoce^ to 

8.4.2 Using the Pen 

Vitalink is designed to be used anywhere, anytime. All data in the Vitalink 
ava ZtT ^ r?Tt T? "* P6n a '° ne - However there are several options 

Ctt^s* data ent * process usin9 a pen - The * - di ~ 
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Writing in Text Boxes 



Each text box is a represented 
by a white box on the form. 
Data can be entered into the 
text boxes by writing in them 
directly, or by utilizing one of 
several editing features 
described in the following 
sections. 



Kidney Data 



Of /: CtomptW 



V tnn tscfwnsc Ten 
C Y«*Q}to . 



n - 'tefeuFfcsh 

iCCJDC 



Fdrt Solution 



T*«rtgM««t«ts '\ 
r BtoodCtat F bCH 



: EnBtoc . 
C V«CMo 



Popup Edit Boxes 



1 — 


Recovering Surgeon 




EE 






: 1— ^ 1 ' 1 ' ' 1 1 1 




1 ' " 1 1 ■ « 1 1 1 1 1 


T 



When the Options, 
Popup Edit Boxes 
menu choice is 
selected, edit boxes 
appear when the pen 
touches a standard 
text box. Text is 

written directly in the combs. The title bar of the edit box displays the name of 
the current field. The icons near the top of the box specify how the data is to be 
interpreted. The following table explains what each icon does for the recognition 
of the ink entered: 



Icon 


Interpreted As 




Alpha characters 


m 


Numbers 




Alphanumeric characters \ 



» — .w. iw. uic <-ui i ci H i iciu ureases me percentage of 

handwriting recognition. A default icon will be selected depending on the data 
type of the current field. Touch the OK icon when data entry is complete 
The Options Menu controls whether or not the popup edit boxes display Popup 
edit boxes can be displayed all of the time, sometimes or not at all See the 
Options Menu section for an explanation of the Options Menu choices 
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Popup Keyboard 



Some users 

prefer tapping out |£« 
words with the 
soft keyboard 
instead of writing 
in the field with 
the pen. This is 
another tool that 
coordinators can 
use to facilitate 
the entry of donor information. 



n |f2 Jr3 > J g |Fjs |F7 |fb I j ra |nojm \n 2 \ 



The Options Menu controls whether or not the popup keyboard displays See the 
Options Menu section for an explanation of the Options Menu choices. 

8.4.3 Special Editing Tools 

In addition to the popup edit boxes and keyboard, there are other editing tools 
which assist in the data entry process. Each of them are described in the 
following below. 



Check Boxes vs. Option Buttons 



SIGN 

O Normal @ Wnk (j 0*is*j 
@y«m O Cpol TtnyfiT" 
r BrutMi (x Lactations : 
I* f" Tattoo* ; 

f~ Track marks 



A check box is represented as a square box 
on the form. When a check box is empty, its 
value is considered false. To mark a check 
box as true, touch the box with the pen, or 
tab over to the field and press the space bar 
on the keyboard. A check box's value can be 
toggled from true to false and visa versa. 
Option buttons are logically grouped together and are mutually exclusive - only 
one can be marked as true. To select an option, touch the appropriate option 
button with the pen, or tab over to the field and use the arrow keys to select the 
desired option. An option button's value is changed by moving or selecting 
another option button within a group. 
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Field History 



Abmgton 


i 




Philadelphia . 


i 




WiDoW Grove 



















Sample list of Home City entries. 



Drop-Down Lists 



Every time a case is created and data is 
collected, each data field retains a lists of 
all previous entries. For example 
"Philadelphia" is entered for the Donor 
Home City field for a particular case. In 
subsequent cases, "Philadelphia" will not 
have to be rewritten, rather the user 
could touch the binoculars icon and 
choose a city from the historical list. 



Race ' I 


White 




Black 
Hispanic 

Indian Subcontinent 
Mideast/Arabian 
North American Indian 
Pacific Islander 


D 




white 






41 



Some fields have specific lists associated with 
them. The example shown here is the standard 
UNOS race list. Touch the appropriate choice with 
the pen to save the data for that field. If you are 
using a keyboard, tab over to the field and access 
the drop-down list by pressing the Alt and down 
arrow keys together. Select the option by using 
the up and down arrow keys and then press enter. 



Date Edit Box 



Admission Date 



Every date field in the Vitalink system 
displays the date edit box. The user can 
easily choose the date for the specific field 
on the calendar. The title bar of the date 
box displays the current field name. Pick a 
date by tapping on the appropriate day. 
Change month and year by pressing the left 
and right arrows. Touch OK when the 
correct date has been chosen. 

The current date is always the default date. 
If the date edit is always displaying an 
incorrect date, check to make sure your system date and time are correct. See 

time St6m MSnU SeCt '° n f0t information on how t0 change the system date and 



i hebruara ► <1<PM> 


Su| Mo] Tu 
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13114115 


16 |17 118 
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20I21I22J 


23124125 


26 


271281 ^i 
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Time Edit Box 



j Admission Time 






"•» ■ 


T 




T • 




02:18 











Every time field in the Vitalink system displays 
the time edit box. The user can enter the 
correct military time by using the up and down 
arrows on the scroll bars to enter the hour and 
minute. Touch OK when the correct date has 
been chosen. 



The current time is always the default time. If 
the time edit box is always displaying an incorrect time, check to make sure your 
system date and time are correct. See the System Menu section for information 
on how to change the system date and time. 



Using Ink on Diagrams 




There are three diagrams in the Vitalink system which can be drawn on: 

0 Initial Physical Diagram 

EI Left Kidney Anatomy 

0 Right Kidney Anatomy 

Use the pen just like you would normally. The drawing icons are a pencil facing 
down (draw mode), and an upside down pencil (erase mode). By selecting one 
of these icons, ink can be drawn on the diagrams to illustrate scars, tattoos, 
bruises, etc. 
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8.5 Data Entry on a Grid 



Serology 



Oats 



H02/24/S jP2/24/34j 



! 14:01 



AntfJUVI 



116:02: 



AntttUVtf' 



AntFHTLVI 



AntKHTLV U 



RPR-VPBL 



NO Not Done 



HBtAp 



Anti-HBC 



AnfrHCV 



Other 



Cownwnn 



Hetuft j Description 



Indeterminate 



j Negative 



I Positive 



m 



Most of the laboratory . 
data is collect in a grid or 
table format. Data entry 
on these forms is 
basically the same as the 
standard form with one 
minor exception. Grid 
column need to be setup 
for each snapshot of 
time. For example, when 
a new grid form is open, 
the only data displayed is 
the name of the rows. 
You can not begin to 
enter date until a new 
column is created. Once 
a new column is created, a date and time is established and the following fields 
are ready for data entry. The following sections explain how this is done. 



i Unknown 



Column Icons 



The plus and minus icons are used to add and delete columns in a grid To add 
a new column, touch the plus icon. This will setup a new column with the current 
date and time. Users can edit the date and time and then enter in data as usual 
The vertical and horizontal scroll bars can be used to view more than one 
column at a time. Users can also resize the grid windows to see more or less 
rows and columns. 

A column must be selected before it can be deleted. To select a column, touch 
he cell just above the Date field. This will highlight the current column. Touch 
the minus icon to remove the column and its related data from the database 
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9. TECHNICAL SUPPORT 



2 l omvirfl t S °? ° f the Pr ° t0tyPe SyStem ' American Management Systems 
w.H provide technical ass.stance from 9 AM - 5 PM EST. Operators will record 
the necessary information and page a Vitalink system analyst. It is essential 
information 9 teChnical Sqpport line that y° u 9 jve the operator the following 

0 Name 

0 Phone number 

0 Time you can be reached 

0 Short description of question/problem 

The Vitalink system analyst will return your call as soon as possible. 

The phone number for technical support will be given to all users of the Vitalink 
system during initial training. 
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Appendix 

Vitalink Sections and Corresponding AOPO Form Page Number 



1 Vitalink Section Name Corresponding AOPO Page 


Case Information 


1 


Donor Information 


J 1 


Consent & Admission Information 


L 1 


Initial Physical Assessment 


2 


Assessment Diagram & Comments 


2 


Medical/Social History 1-10 


3 


Medical/Social History 11-19 


3 


USPHS Criteria & Respondent Data 


3 


Chemistry 


4 


Urinalysis 


4 


CBC & Diff 


4 


Serology 


4 


Microbiology 


4 


Hemodynamics/Temperature 


5 


Intake/Output 


5 


Intropic Support 


5 


Cardiac Data 


6 


Pulmonary Data 


6 


Arterial Blood Gases j 


6 


Medications 


7 


Intraoperative Management 


7 


Kidney Data 


8 


Left Kidney Anatomy 


8 


Right Kidney Anatomy 


8 


Heart Data 


9 


Lung Data 


9 


Pancreas Data 


9 


Liver Data 


9 


Tissue Data 


9 


Notes 


10 j 


Disposition "i 


11 
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ORGAN INFORMATION SERVICE DESIGN DOCUMENT 



EXECUTIVE SUMMARY 



American Management Systems, Inc. (AMS) is pleased to present the United 
Network for Organ Sharing (UNOS) with the Design Document for the Organ 
Information Service (OIS). The OIS will revolutionize the transplant process by 
providing Organ Procurement Coordinators with a new way to collect and 
communicate donor data. 

The OIS is a data collection and dissemination tool designed for the unique 
requirements of the organ sharing community. It is application software 
combined with various types of mobile computers and communication methods. 
OIS will compress the existing transplantation process by capturing donor 
information in an electronic format in the field and by supplying a network for 
donor information communication. 

The OIS will be used by Organ Procurement Coordinators in the field to collect 
donor information and to transmit the data to UNOS headquarters. The 
coordinator will have an interface to the UNOS Match Run through the OIS. The 
communication of donor information to members of the transplant community 
may be done electronically through the OIS system, or sent through the OIS fax 
and pager gateways. Donor information will also be accessible through a touch- 
tone phone. 

The data elements collected by the OIS are combined from three main sources- 
the Association of Organ Procurement Organizations form; the UNOS Cadaver 
Donor Registration form; and the Match Run donor record. The data collected in 
OIS can be considered UNOS's donor data collection form. 

The OIS Design Document is meant to serve as a guide during the development 
phase for the AMS and UNOS project teams. As development progresses, the 
design may need to change to accommodate various circumstances. Any 
changes to the design will be documented and presented to UNOS for approval 
The complete OIS will be delivered to UNOS in January, 1 995. 
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BACKGROUN D 

Originally established in 1977 by members of the South-Eastern Organ 

mMnS ment Ration (SEOPF). the United Network for Organ Sharing 

ro™2S S >* To" 8 ' °: 9an Procur ement and Transplantation Network 

STV£S?i '° n SC ' ent,f,C RegiStry for 0r 9 an Transplantation. In this 
role, UNOS funct,ons as a contractor for the federal government and a private 
non-prom corporat.cn. Under contract with Health Resources and Services 

flT^h on i HRS ^' U D N0S has operated the 0P ™ since sSSESS. 

1 986, and the Scientific Registry since September 30, 1 987. 
American Management Systems, Inc. (AMS) is the developer of the Organ 
Information Service (OIS) application software in conjunction with UNOS AMS 
imnfnl ,h n / a,rf H ' Vir 9 ini \ Founde d * 1970, AMS specializes in helping clients 
A^r,l P erformance through the intelligent use of information technology. 
Icttmc h ? SpeC,f ' C mdU$try ex P erience . business function expertise, proven 
romnTtt ? °f T 0t and an extraordinary depth of technological 

competence to help our clients meet their business goals. 

StHhoTH n9 u ta !r c entS W6re taken from the 1993 UN0S An ™*' Report and 

o Resources ^d Services Administration (HRSA) goals for the 
National Organ Procurement and Transplantation Network (OPTN): 

> Improve the effectiveness of cadaver organ procurement and distribution. 

> Increase patient access to state-of-the-art transplantation .technology. 

> Improve the system for sharing renal and extra-renal organs so as to 

► facilitate matching of donors and recipients, based on specific criteria 
established for each organ, 

► improve transplantation outcomes. 

► provide a system by which immunologically sensitized patients are 
afforded the best possible opportunity to be matched with a 
compatible donor, and 

>• decrease the wastage of organs. 

> Assure guality control by collection, analysis, and publication of data on 
organ donation, procurement and transplantation. 

> Maintain and improve professional skills of those involved in oraan 
procurement and transplantation. y 

The OIS will provide the foundation for improvements in each of the above 

3T63S, 

In November, 1 993 UNOS and AMS met to discuss how to change the current 

^leSZ™Si 0athe,in9 f[° CeSS fr ° m 3 seria,/manual ™thod to an efficient 
Soon int^ t Pr0C6SS - The number one 9° al of im P'ementing an automated 
S^^Er ton H Pro0888 iS t0 S3Ve more ,ives - UN0S want * to provide a 
ZTtZZ itt 0 ^°!, eC V he rGd dOPOr information in the field and have that 
data transmitted electronically back to UNOS headquarters. Automating this 
mitial process encompasses the scope of the original Vitalink prototype. 9 
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The Vitahnk prototype automated the collection of the data on the Association of 
Organ Procurement Organization's (AOPO) form. The prototype, complete with 
wireless data communications, was delivered on January 31, 1994. The Pilot 
Results Report was delivered on April 29, 1 994. 

The Vitalink prototype as it exists today is a data collection tool designed for the 
unique requirements of the organ sharing community. The prototype consists of 
custom application software combined with pen-based, hand-held computers 
and wireless data communications. Vitalink supports Organ Procurement 
Coordinators in the field by collecting and transmitting the essential donor 
information to the UNOS Organ Center so that a Match Run can be executed at 
UNOS. Vitalink provides a mechanism to standardize the data collected on 
donors to increase the chance of organ placement. 

Through the feedback gathered from the pilot, AMS has concluded that the most 
important issue is to not only to collect the data, but to make the data available to 
all of the professionals involved in the transplantation process. UNOS will 
expand its role in the organ transplant community by becoming the national 
clearinghouse of organ sharing information. The OIS system achieves this 
objective by utilizing the Lotus Notes platform. 

Lotus Notes provides the infrastructure on which UNOS can build its long term 
vision of an automated organ information sharing system. 

July, 1 994 marked the start of the design phase for the production system 
referred to in this document as the Organ Information Service (OIS). The OIS 
encompasses the collection of data from three sources: The AOPO form, the 
Cadaver Donor Registration (CDR) form and the Match Run donor record' used 
to run matches at UNOS. OIS facilitates the access to essential donor 
information to all appropriate transplantation professionals. 



During the months of July and August 1994, AMS and UNOS conducted further 
requirements analysis for the OIS system. 



Meeting Date 


Location 


Purpose 


July 7 


UNOS 


Design kick-off 


July 12-13 


UNOS 


Data fields and Match Run review 


July 28 


UNOS 


Requirements analysis 


August 2 


UNOS 


Requirements analysis 


August 22 


AMS 


Match Run planning 


August 24 


UNOS 


Lotus executives briefing 


August 26 


UNOS 


Match Run staff questions and review 


September 1 


AMS 


Organ Center staff members input 


September 16 


AMS 


Review of design document 



The design of OIS has been an ongoing process since the start of this project in 
November, 1993 and has resulted in the culmination of this document. 
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INFORMATION STRATEGY 



In order to be useful, information should be stored in a way that makes it readily 
accessible to those who need it most. Lotus Notes is a platform in a new class of 
systems called "groupware". These systems have emerged because traditional 
tools were not designed to support the creation, flow, and tracking of information 
in direct support of business processes. Lotus Notes has an architecture 
designed specifically to support the management and sharing of knowledge 
while traditional database systems are transaction-oriented and cannot easily 
support occasionally connected users. 

An organizations* knowledge system should be: 

■ Extremely open 

■ Topology-independent 

■ Designed to support the sending and sharing models 

When putting together an information strategy, it is important to understand the 
difference between back-end information storage systems and front-end tools 
that act upon the information itself. A back-end information storage system can 
be thought of as the infrastructure that stores and disseminates information 
throughout the organization. It is the middleware that works in conjunction with 
operating systems and networking software in order to manage the distribution of 
data and to ensure the security of the system. 

Dictating which hardware and communication methods to use is risky. 
Technology changes daily and many organizations and users have strong 
emotional feelings about the purchase of hardware. Lotus Notes runs on the 
most widely used operating systems and hardware including IBM compatible 
workstations, notebooks, sub-notebooks, pen-based computers, and Macintosh 
products. By developing on the Lotus Notes platform, users are not limited to 
specific operating system, hardware and communication options. 
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Workstation Pen computer 



UNOS is out of me hardware and communication specification business with a Lotus Notes development platform. 



The feedback gathered from the Vitalink prototype dictated that UNOS must 
think beyond the concept of providing a data collection tool (Vitalink) and 
concentrate on setting strategies that involve back-end infrastructure deployment 
(OIS). Lotus Notes provides a platform that meets the needs of the OIS and 
provides a foundation that may be used to manage all information aspects of the 
organ placement process. 
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THE NOTES PLATFORM 



This section is a compilation of information taken from "Lotus Notes* A System 
for Managing Organizational Knowledge" published by Lotus Notes Support 
Services. 

Notes is a platform that is specifically designed for the development of 
customized, communication-based or information-based applications. Lotus 
Notes was first deployed in 1989. Today there are over 500,000.site licenses of 
Notes. 

Client/Server Architecture 

Notes is implemented as a modular, client/server system with support for many 
operating environments both on the client and server sides. Access to the data 
is controlled by the server at a very fine level of granularity, which requires a 
smaller amount of data to be passed between a user's workstation and the 
remote server. Clients are available on Windows, IBM OS/2 Version 1.x and 2 x 
Macintosh System 6 and 7, and various UNIX implementations. Servers are 
available on all the above with the exception of the Macintosh, and is available 
as a Netware Loadable Module (NLM) for Novell's Netware network operatinq 
system. 

Open Standards 

Notes supports a wide range of industry standards that provide the ability to 
move data into and out of Notes using standard formats and protocols in addition 
to the Notes API: 

Messaging standards, X.400 and the Vendor Independent Messaging 
group (VIM); 

Naming standards, X.500-compliant hierarchical naming; 
Authentication, X.509 Notes is an industry leader in the use of public 

key/private key cryptography in the areas of authentication and 

messaging; 

Encryption, Notes licenses the RSA Public Key Cryptosystem developed at 
MIT and licensed by Public Key Partners/RSA, Inc. and utilizes this set of 
services in all aspects of Notes security; 

Bento, Lotus plans to embrace the cross platform document architecture in 
future releases; 

SQL, Notes will support connectivity to relational databases through ODBC 
(the Windows Open Database Connectivity interface); 

Openness at all levels, Notes is designed so that each of its base services 
may be augmented or replaced by components provided by a third-party 
vendor. 
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Replication 

Notes uses a process called replication, which is the process of keeping multiple 
copies of a database in synchronization with each other. The replication process 
is optimized for broad dissemination of information shared among many 
individuals. Replication supports virtually any topology and is the centerpiece of 
the occasionally-connected usage model. 

Scaleable Implementation 

The Notes server was designed with scaleability in mind. As more clients are 
added to the system, the Notes server may be upgraded to a more powerful 
hardware platform. Notes has just released its NLM server and has plans for a 
Windows NT version. 

Distributed Manageability 

In a system consisting of potentially many servers, it would not be feasible to 
have a network administrator assigned to every server. Notes allows any server 
to be managed and configured remotely. Notes servers generate alerts that can 
be fed to network administrators through electronic mail. UNOS will need to 
invest time into training one or more of their IS staff to become Lotus Notes 
administrators. 

System Updates 

Notes not only replicates data, it also replicates changes made to Notes 
applications. Design changes are replicated throughout the user community 
automatically when users connect to the server at UNOS. 

Security 

Lotus Notes was developed from the outset as a secure system. Done in a 
manner that works across vendors' operating environments, Notes utilizes 
technology licensed from RSA, Data Security, Inc., the industry leader in 
cryptographic algorithms and services. Notes provides four classes of security: 

Authentication, which securely identifies users using the industry-standard 
X.500 hierarchical naming syntax. Authentication in Notes is bi- 
directional, that is, servers authenticate the identity of users andusers 
authenticate the identity of servers. Authentication is used whenever a 
user and a server, or two servers, are communicating with each other . 

Digital Signatures, which provide users the absolute guarantee that a given 
message is from who it says it's from, essentially a useMo-user form of 
authentication. In addition, this technology enables the computer to 
notarize all or a portion of a message, thus making the guarantee to its 
recipient that the message has neither been forged nor altered in transit. 

Access Control, which provides the ability to grant or deny access to 
shared databases, documents, views, forms, and fields. Server access 
can also be controlled for individual users by either allowing or denying 
access to specific Notes servers within the organization. 
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Encryption, which involves ciphering or scrambling information so that even 
if it were accessed by the wrong individuals, it couldn't be understood. 
Encryption is available at three levels in the system., At the message 
level, individual messages can be encrypted for one or more intended 
recipients; At the network level, encryption prevents someone from 
promiscuously •sniffing" (tapping into) traffic on a LAN or dial-in line, 
because they won't see anything intelligible; at the field level, databases 
can be designed to encrypt document fields so that only specified users 
can read them. 

The security in Notes works across vendor platforms, so it is managed and dealt 
with in the same way regardless of which operating system you choose to use. It 
works with any topology that you choose, so that occasionally-connected users 
or LANs are managed the same way as a single server or LAN. 

Lastly, there are no back-doors into the system. Because of its fundamental 
design, neither Lotus nor any hacker, foreign or domestic government agency, or 
competitor has or will have a "super user" capability in a Notes information 
system. 

Open Data Integration 

In addition to inter-application data exchange facilities, a second level of data 
integration is achieved through use of Notes 1 set of import/export filters. Local 
organ procurement organizations may use import/export filters to exchange data 
with their own Donor Management Systems (DMS). 

Dial-Up Notes 

Dial-up Notes allows the use of Notes at remote sites where there is no LAN- 
based Notes installation. Notes will work with most popular brands of 
symmetrically modulated modems which recognize the Standard AT Command 
Set (the commands used in Hayes Smartmodems up to 2400 bps). Notes 
supplies modem command files for over 60 models, in addition to a template and 
instructions for creating new files for uncertified modems. Dial-up Notes supports 
asynchronous communications scripts to allow connections to X.25 networks and 
other applications that require extended communications support. 

Notes Mail 

Lotus Notes contains a world-class mail and messaging system that has an 
interface designed to be easy to use and consistent with that of the rest of the 
Notes product. 
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NOTES DEVELOPMENT TOOLS 



After Notes had been chosen as the infrastructure on which to base OIS AMS 
evaluated development tools that offer an alternative to the standard Lotus Notes 
interface. Three alternative development tools were evaluated: 

Lotus Forms 

Lotus Development Corporation announced the availability of Lotus Forms on 
June 27, 1994. Lotus describes Lotus Forms as "a powerful, production form 
workflow solution based on a messaging-reliant, client-based workflow model 
with sophisticated routing, tracking and security." Lotus Forms offers a 
development environment for form-based workflow systems. 

Visual Basic 

Microsoft Visual Basic was used for the Vitalink prototype and was considered as 
an alternative interface to the Notes infrastructure because of its support of Pen 
aware objects. VB is a programming language for Microsoft Windows that 
includes a robust development environment as well as extensive third party 
support for extended objects. Visual Basic has been the GUI language of choice 
for the AMS Mobile Computing Group for the past two years. VB/Link for Lotus 
Notes is a VBX for Visual Basic that enables VB to read and write Notes data. 

Lotus ViP 

Lotus Development Corporation announced the availability of Lotus ViP Visual 
Programmer for Notes on June 28, 1994. ViP is "a visual application 
development environment that combines the power of Lotus Notes with unique 
Visual Linking tools to enable corporate developers, Lotus Business Partners 
and ISVs to build a new class of strategic groupware applications. Notes ViP 
extends the market-leading Notes groupware platform in four key areas: 
integration of Notes and corporate data stores; building of sophisticated 
graphical user interfaces; enhanced programmability in the Notes development 
environment; and the ability to create complex reports, charts and graphs." The 
ViP language is based on LotusScript 2.0, a BASIC-compatible language that 
has been enhanced to allow development of event-driven applications. 

Conclusion 

Lotus Forms would not be effective for the OIS because it supports a different 
data model than that required by the OIS. 

Both VB and ViP are excellent GUI development environments, but do not 
provide tight enough integration with Notes to provide a seamless application. 
VB and ViP should be used when data needs to be integrated from many 
sources, and when it is necessary to chart and report Notes data. Notes itself 
was designed to manage data entry and retrieval of form based data. If the OIS 
application was developed in VB or ViP, the user would be required to perform 
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some actions from the Notes client software. It is necessary for the user to 
understand Lotus Notes client software. If the OIS application is written outside 
of Notes, the user must learn that interface as well. Having the user jump from 
the VB/ViP OIS system to the Notes client software would make the system 
appear fragmented and confusing. The OIS application needs to be in one 
environment that can provide consistency of interface, and tight integration of all 
components. 

Notes databases are more than just databases, they are applications that 
contain views, forms, and system logic. Notes servers must retrieve data for 
clients based on views and forms that must be developed and stored in each 
Notes database. The Notes application must be developed before a VB or ViP 
application is designed. If the OIS were developed in VB or ViP it would emulate 
the forms and views that already exist in the Notes database. A Notes 
application interface developed in VB or ViP is only a shell and extension to an 
existing Notes database application. 

The OIS is based on the ease of remote user communications. VB does not 
support dialing in to a Notes server and ViP only supports a very limited dial up 
capability. For example, ViP requires the user to go into the actual Notes ciient 
software to hang up a remote connection. 

Graphics can only be stored in a Notes Rich Text field which VB and ViP do not 
support.- The OIS application needs to have diagrams that the user may 
annotate. 

VB and ViP offer excellent GUI design environments and contain a better 
scripting language than Notes. This makes it tempting to use VB or ViP to 
develop OIS, but because VB and ViP lack a tight integration with all of the 
Notes components, AMS believes it would be risky to develop OIS using VB or 
ViP. Lotus Notes 3.1 1 offers an integrated environment that contains all of the 
components necessary to build an effective system to collect, manage, and 
communicate donor information. 
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SYSTEM OVERVIEW 

This section contains a general description of the Notes concepts that make up 
the OIS application. 

Notes Databases 

In Lotus Notes, the database is the foundation of the application; it is possible to 
use the terms "application" and "database" interchangeably. A Notes database 
is a collection of related documents stored in a single file. In Notes, each 
database is represented on the workspace with an icon. Information in a 
database is organized and maintained with five basic building blocks: forms, 
fields, sections, views, and documents. 

Documents 

Lotus Notes uses a document oriented database. Documents are the "records" 
in the OIS application; it is similar to a "row" in a relational database. Information 
in a document may be entered by a user, calculated by formulas incorporated in 
the database design, imported from other applications, or linked to another 
application and dynamically updated. Like the database itself, a document can 
be any size. A single document may contain only a few alphanumeric 
characters, or several pages of text and graphics. 

Forms 

A form defines the format and layout for documents. Each form can contain 
fields, static text, graphics, and buttons, which determine how users enter 
information, and then how that information is processed and displayed. When 
you compose a document, the form that you are using determines which fields 
are included in your document, and how they are placed. If you later view that 
document through a different form, you may not see all of the same fields. 

A database can have any number of different forms, according to how it is used. 
For example, the OIS Donor Information database contains Donor Information 
forms, ROP Tray Data forms, and Match Run forms. 

Fields 

A field is a named area of a form that contains a single type of information. A 
form can have an unlimited number of fields. Depending on its data type, the 
value of a given field can be as small as a single character, or many pages of 
text and graphics. 

Sections 

A section is a special type of field that logically defines an area of a form or 
document. Within a section, you place fields and static text; access to that 
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section of the document can then be controlled so that only authorized users can 
edit the data within the section. 



A view is a tabular summary of the documents in the database. Most databases 
have several views, each sorting, selecting, and categorizing the documents in a 
different way. For example, the Donor Information database may order 
documents by donor name in one view and by UNOS ID in another. Each row in 
a view represents a document. Views are used by users to access documents in 
a database. 



The OIS system utilizes all aspects of Notes security but there are two levels of 
security that an OIS user should understand; database level and document level. 
Users of the OIS system are given a default type of access to a database and 
are given the ability to refine access control at the document level to allow 
access to those who need to see donor information. 

The access control list (ACL) of a Notes database consists of: 

• No Access - Absolutely no access to the database; users can not even add 
the database icon to their workspace. 

• Depositor - Users can compose documents, but can not read any - not even 
the ones they composed. 

• Reader - Users can read documents, but can not compose any. 

• Author - Users can compose documents, read documents, and edit the ones 
they composed. 

• Editor - Users can compose documents, read documents, and edit any 
document regardless of who composed them. 

• Designer - Users have Editor access, plus they can modify the database 
icon, About database document, Using database document, and all design 
elements (fields, forms, views, and macros). 

• Manager - Users have designer access, plus they can define replication 
settings, modify the ACL, and delete the database. 

In addition to the access levels described above, Notes provides options that 
control whether a user can create or delete documents. 

The OIS system will also utilize two special fields in some documents called 
Author Names and Reader Names. 

Author Names is a text list of user names that indicates who can edit a given 
document. The author names field cannot override the access control list, it can 
only refine it. Users who have been assigned an access level of No Access to a 
database can never edit a document, even if they are listed in the document's 
Author Names field. Any user with Author access to the database who is listed 
in the Author Names field has read and write access to the document, even if he 
or she did not create the document. 



Views 



Security 
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The Donor Information document will contain a Author Names field that is 
editable. This field will always contain the user name of the person saving the 
document. The author may add names of other users to the Author Names field 
allowing them to edit the document as well. One person should manage the 
editing of a document to prevent editing conflicts, however the Author Names 
field may be used if the case is being passed from one coordinator to another. 

Reader Names is a text list of names that indicates who can read a given 
document. Reader Names is similar to Author Names, except that it controls 
read access to a document instead of edit access. This is a very important field 
in the OIS system because it controls not only who can read a document, but 
who can replicate the document to their local machine. Users whose name does 
not appear in the Reader Names field will not even know that document exists. 

Replication 

Replication is the process of synchronizing two Notes databases. Users in the 
field will dial in to the OIS Notes server and replicate their copies of OIS Notes 
databases with the OIS Notes databases on the server. It is important to 
understand that all data and relationships between the data are stored locally 
and on the Notes server. When a user modifies a Donor document on their local 
machine that modification cannot be seen by others until replication occurs. 

When users replicate the Donor Information database, only documents that have 
that user in the Reader Names or Author Names fields get replicated between 
the user and the server. The field user will not receive all of the Donor 
Information documents that are on the server, they will only receive the ones 
they have composed, and the ones that have their user name in the Reader 
Names field. 

All data validation and system databases are also replicated with users in the 
field to ensure that local copies of reference databases are up to date and 
accurate. 

OIS In The Field 

This section will briefly describe the way a Organ Procurement Coordinator might 
use the OIS to manage donor information during the placement process. 

1 . After consent has been obtained and the coordinator begins to gather donor 
information, the coordinator selects the Donor Information database on their 
Lotus Notes desktop and composes a new Donor Information document. 

2. After the coordinator has entered enough information in the document for a 
Match Run, they press the Request Match Run button on the Donor 
Information Match Run Input form. The OIS will check the Match Run Input 
data and issue warnings for data that is invalid. Some errors will require 
correction, such as missing data in a required field, but most error messages 
give the user the ability to proceed with the Match Run. Following data 
validation, the OIS field unit calls the OIS Notes server in Richmond and 
delivers the Donor document to the Match Run Request database. 

3. The coordinator may disconnect from the Notes server after the Donor 
document has been transmitted, or may remain connected to wait for the 
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Match Run Results. The user will receive a mail message from the Match 
Run process indicating success. The coordinator may then replicate the new 
Match Run Results document to their field unit and view it. 

4. After the coordinator reviews the Match Run Results, the coordinator may 
wish to send fax or page notification to a person or center. To send a page 
notification, the user presses the page button on the Match Run Results form 
to compose a Pager form. The Pager form can be addressed to a center or 
an individual that has registered their pager with the OIS to notify them when 
donor information is available. 

5. Once the Notification documents have been created, the coordinator needs 
to replicate with UNOS to forward the Notification documents to the fax 
and/or pager gateways. 

6. If a center receives a page or fax notification and they have a Notes client, 
they may replicate with the OIS server to receive the donor information. The 
center may also call the Phone Notes client with a standard touch-tone 
phone to request a fax of the donor information. 
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OIS NOTES DATABASES 



The OIS involves the creation of a Lotus Notes network for UNOS. The network 
topology for this network is fairly simple because it consists of one Notes server, 
UNOS_OIS_1 , that is accessed by remote users via modem or by the UNOS 
Organ Center over the UNOS Pathworks network. This section describes each 
of the Notes databases that comprise the OIS application. 

The User Access sections in this document explain the OIS field user's access 
level of each database. OIS system administrators have Manager access to all 
OIS Notes databases. 

UNOS's Public Name & Address Book 




Data Validation Lists OIS User Infofmation Center Information 




Description 

The UNOS Public Name & Address Book contains a directory of the OIS users 
as well as a set of documents for server communications and management. 
When a user is registered in the OIS, a person document is created for that user 
in the Name & Address book. The person document contains e-mail addressing 
information, contact numbers, personal and miscellaneous information. When 
registering users with the OIS, the system will take advantage of Lotus Notes 
distinguished naming to supply user names. A Notes user name can consist of 
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the user's name, 0-4 organizational units, organization, and country. The OIS 
will use center names for the organizational units. The user name of a 
coordinator from then Indiana Organ Procurement Organization might be: 

"Joe Smith/INOP/UNOS" 

Because the OIS is based around the concept of data sharing, it is import to be 
able to uniquely and easily identify other users of the system. Users who author 
donor information in the system have the ability to grant Reader access to other 
users of the system. The Name & Address book contains the names of all the 
OIS users as well as groups that contain multiple users. The Name & Address 
Book will have a group name for every center that contains all of the OIS users 
in that center. This allows a coordinator to grant Reader access to individual 
users by using user names, or to all users at a particular center by using group 
names. The Name & Address book is critical to the movement and sharing of 
data in the OIS system. 

User Access 

All field users will have Reader access to this database. 
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UNOS Centers & Providers 




Description 

The UNOS Centers & Providers database contains a document for every center 
and provider that is registered with UNOS. Center documents contain 
information used by the OlS system as well as page and fax contact numbers. 
The center name in a user's distinguished name must be one of the center 
names in this database. This database will be used for data validation when 
entering center and provider information in the OlS Donor Information database, 
and will be used to associate Match Run variances with centers. 



User Access 

All field users will have Reader access to this database, with the ability to modify 
the center document of the center to which they belong. This database may be 
viewed by users for reference but it is primarily designed for system access. 
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OlS Data Validation 




Data Validation Lists OlS User Information Carter Information 




Description 

This database contains all of the field level lookup data used in the OlS 
application for lookups and data validation. Reference data may be updated by 
the OlS system administrator. Any OPO that may have their own Donor 
Management System will be able to export this database to ASCII files to have 
the most current data validation lists. 

User Access 

All field users will have Reader access to the OlS Data Validation database. This 
database may be viewed by users for reference but it is primarily designed for 
system access. 
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OlS Donor Information 




Data Validation Lists OlS User Information Carter Information 




Description 

The Donor Information database is the heart of the OlS system. This is where 
the coordinators enter all donor information and other OlS users come to view or 
print donor information. The following sections outline what is contained in the 
Donor Information database and how it interacts with other databases in the OlS 
application. 

The Donor Information database consists of three major documents: 

• Donor Information 

• Match Run Results 

• Tray Results 

This database is unusual in the fact that there are over 25 different forms used to 
view the Donor document. In the other OlS Notes databases, each document (a 
record in the database) has only one form (record layout) to view that document 
with. Each form will read and write data to the same Donor document, but will 
provide access to different sections of the Donor document. A field from the 
Donor document may appear on more than one form, but points to the same 
data in the document. This concept allows the OlS to logically group sections of 
data and present subsets of the Donor document to the user. 
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User Access 

The documents in the OIS Donor Information database have two special fields 
called Reader Names and Author Names. When a document is composed, that 
user's name is placed into the Author Names field. All users are granted Author 
access to the database as a default. This means any user can compose and 
save a new document, and then edit that document at a later time, but the user 
is not allowed to edit a document they did not author. Notes keeps track of who 
can edit a document via the Author Names field. If the author of a document 
adds other user names to the Author Names field, then those users may edit the 
document even though they were not the original authors. 

The Reader Names field allows the author of a document to limit who can view 
the document. Only users whose name appears in the Reader Names or Author 
Names field can view a document. The Reader Names field will always contain 
a group of system administrators, the UNOS Organ Center, and the current user. 
The author of the document may add user names to the Reader Names field to 
grant them access to view the document. Users listed in the Reader Names field 
may not edit the document. Only users listed in the Author Names field may edit 
the document. This enables the coordinator to control who may view and edit 
their case. 

The users in the Organ Center have Editor access to the OIS Donor Information 
database. They will be able to view all documents in the database because a 
group containing the names of the Organ Center users is always contained in 
the Reader Names field of each document. The Organ Center will also be able 
to modify any document in the database even if they are not in the Author 
Names field because they will be granted Editor access to the database through 
the access control list by default (all other users will be given Author access). 
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Donor Document 

The most data-intensive OIS document is the Donor document. The Donor 
document has over 25 forms used to enter data. All of the fields contained in the 
forms are located in the Appendix. Each form is described in the following 
paragraphs. 

Donor Document Forms 

• Donor Form Navigation • Medications 

• Case Information • Cardiac Data 

• Donor Information • Pulmonary Data 

• Consent & Admission • Intraoperative Management 

• Initial Physical Assessment • Kidney Data 

• Medical/Social History • Heart Data 

• Chemistry • Lung Data 

• Urinalysis • Pancreas Data 

• CBC&Diff • Liver Data 

• Serology • Tissue Data 

• Microbiology • General Notes 

• Hemodynamics/Temperature • Organ Recovery 

• Intake/Output • Match Run Input 

• Arterial Blood Gases 



The Donor document was created by using the data collected from three 
sources: 

• Association of Organ Procurement Organizations form (AOPO) 

• Cadaver Donor Registration form (CDR) 

• Match Run Donor record (MR) 

Some of the data fields overlap, and some were unique to each source. This 
new Donor document will be UNOS's standard form for collecting donor 
information used to place organs. 

Every Donor document form will have navigation buttons at the top, allowing 
users to quickly and efficiently move from one part of the form to another. 




The Previous and Next buttons move the users from form to form in the order 
listed above. The Jump button pops up a list of Donor document forms the user 
can choose to move to. The Print button displays a list of Donor document forms 
the user can choose to print. The user may choose one or many sections to 
print, or select the 'All Forms' option in the list to print the entire Donor 
document. The Home button returns the user to the Navigation form which is 
described in the next section. 
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Donor Form Navigation 



Ssft^iMi giB&gSffifi 

m&m m*m wmm m&m 


inn 


OIS ID: 092094130712345 UNOS ID: HIT847 Donor Name: Bru*n 1 *y 

BB88fll 


<§> Donor Form Navigation 




O Case Information 




O Donor Information 




O Consent & Admission 




O Initial Physical Assessment 




O Medical/Social History 




O Chemistry 




O Urinalysis 




O CBC&Diff 




O Serology 




0 Microbiology 




O Hemodynamics/Temperature 




, O Intake/Output 




O Arterial Blood Gases 




O Medications 




O Cardiac Data 




O Pulmonary Data 




O Intraoperative Management 




O Kidney Data 




O Heart Data 




O Lung Data 




0 Pancreas Data 




O Liver Data 




O Tissue Data 




O General Notes 




O Organ Recovery 




O Match Run Input 





The Navigation form is another utility used to guide the user through the forms of 
the Donor document. Pressing the Home button will return the user to this form. 
Each section of the Donor document is represented in a list. Users may move to 
different forms by selecting a form name in the list and pressing the Go To Form 
button. 

The Navigation form is also where coordinators will have the ability to grant 
Reader access to other users for their case as well as send fax and pager 
notification to coordinators and centers. 

Only the most basic fields are on the Navigation form. This includes fields such 
as the OIS identification number, donor name and UNOS ID. 



| k I /'"NQ United Network ~~ 

LJNWvJfor Organ Sharing 24 BIT15 Am.r1c»n M*napeai«ftt Syttwn* 



ORGAN INFORMATION SERVICE DESIGN DOCUMENT 



Case Information 

The Case Information form contains general information about the donor case. 
Fields include the coordinator's name and phone number, OPO name, donor 
hospital information and admission date and time. 



Lookup Fields 



Field Name 


List Name 


CaseType 


CaseType 


ReferralType 


ReferralType 


DonorCenterName 


Centers file 


DonorCenterCode 


Centers file 



Donor Information 

The Donor Information form houses all of the demographic data, initial blood and 
HLA typing of the donor. This is also where the user indicates the cause of 
death and whether or not the case is under review by the Medical Examiner. 

Lookup Fields 



Field Name 


List Name 


CauseofDeath 


CauseofDeath 


MechanismofDeath 


MechanismofDeath 


CircumstancesofDeath 


CircumstancesofDeath 


Race 


Race 


A1 and A2 


AHLA 


B1 and B2 


BHLA 


DR1 and DR2 


DRHLA 


ABO 


ABO 1 
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Consent & Admission 

The Consent & Admission form has organ consent information in the same 
format as the CDR form. Users indicate if consent was requested and/or 
obtained by checking yes or no for each organ. If request or obtained answers 
are no, then the user enters in the appropriate reason code. The admission 
section is where users record information about how and why the donor was 
admitted to the hospital. 



Lookup Fields 



Field Name 


List Name 


ApproachedBy 


ApproachedBy 


KidneyObtainedReason 


OrganConsentReason 


LiverObtainedReason 


OrganConsentReason 


IntestineObtainedReason 


OrganConsentReason 


PancreasObtainedReason 


OrganConsentReason 


HeartObtainedReason 


OrganConsentReason 


LungObtainedReason 


OrganConsentReason 


TissueObtainedReason 


OrganConsentReason 



Initial Physical Assessment 

The Initial Physical Assessment form mimics page 3 of the AOPO form. 
Pulmonary, Cardiovascular, Gastrointestinal, Genitourinary and Musculoskeletal 
areas are assessed and recorded in this form. The form also contains a picture 
of the human anatomy that the coordinator may annotate with text and graphics. 

Medical/Social History 

The Medical/Social History form is one of the larger forms in the Donor 
document. This form is divided into three sections. The first section gathers 
data about who is responding to the questions and what their relationship is to 
the donor. The second section contains questions that are specific to UNOS. 
These questions are taken directly from the CDR form. The last section is the 
entire USPHS criteria for exclusion of high risk donors. There is a slight overlap 
of questions from the UNOS specific section and the USPHS section, but AMS 
did not want to omit any information from either section. A thorough review of 
this form's contents will be needed. 



Lookup Field 



Field Name 


List Name 


CancerSite 


CancerSite 
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Lab Data - (Column Entry Forms) 

These forms contain lab data that is collected on the AOPO form. Notes does 
not have the ability to dynamically add columns/therefore there will be a 
maximum number of columns that can be utilized for each form and for each 
donor. There is no additional overhead for storing extra column fields because 
Notes does not save the data definition in a form, rather it is saved in the 
template. Each form will have a comments field for recording additional 
information. 



Form 


Maximum Columns 


Chemistry 


50 


CBC & Diff 


10 


Urinalysis 


10 


Hemodynamics/ 
Temperature 


40 


Intake/Output 


10 


Arterial Blood 
Gases 


10 


Medications/ 
Drugs 


10 



Lookup Field 



Field Name 


List Name 


DrugName 


Medications 
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Serology and Microbiology 

Unlike the lab data, the Serology and Microbiology forms are fixed column forms. 
The Serology form has lookups for each entry and both forms will have a 
comments field for recording additional information. 



Lookup Fields 



Fiplri Namp 




Pn«;tAnti-HI\/1 

i Uo L/AI III Ml V 1 


Oct uiuyy 


Pn<;tAnti-HIV? 
ruoirM in i 1 1 v c~ 


oci ciuy y 


PnctAnti-MTI \/1 


ociuiuyy 


PndtAnti-HT! VP 


ociuiuyy 


Pn^tRPR-VDRI 
ruoinr n vuml 


oci uiuyy 


Pnct A nti-P MV 

1 LroLrM 111 vlvl V 


oti uiuyy 


PostHBsAg 


Serology 


PostAnti-HBC 


Serology 


PostAntiHCV 


Serology 


PreAnti-HIV1 


Serology 


PreAnti-HIV2 


Serology 


PreAnti-HTLV1 


Serology 


PreAnti-HTLV2 


Serology 


PreRPR-VDRL 


Serology 


PreAnti-CMV 


Serology 


PreHBsAg 


Serology 


PreAnti-HBC 


Serology 


PreAntiHCV 


Serology 



Cardiac Data 

The Cardiac Data form contains interpretations for EKG, ECHO and 
Angiography. There are two fields, Drug and HeartRhythm, which were said to 
have lists associated with them, but AMS has not received the lists from UNOS. 
The Drug field could use the generic medications lookup table, however it would 
be more appropriate to obtain a list specific to the Cardiac Data form. There is 
also the capability of adding more than one drug and dosage, unlike the current 
AOPOform. 

Pulmonary Data 

The Pulmonary Data form contains interpretations for Chest X-rays and a 
Bronchoscopy. Chest measurements are also entered on this form. There are 
only two places in which to enter chest X-ray data on the AOPO form. The 
Pulmonary Data form is capable of recording five chest X-ray entries. 

Intraoperative Management 

The Intraoperative Management form is the place where users will record data 
pertaining to the actual surgery and removal of organs. OR teams, Medications, 
Blood Products and specific dates and times are entered on this form. The CDR 
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form specifically asks for medications given in the 24 hours prior to organ 
removal. That data will be collected in this section. 



Lookup Fields 



Field Name 


List Name 


BloodProducts 


BloodProducts 


Medications 


Medications 



Kidney Data 

The Kidney Data form is a data intensive form. It contains all data pertaining to 
both the left and right kidney once they have been removed from the donor. 
There are three sections to this form. The first section contains data common to 
both kidneys. The second section is for the left kidney anatomy and the last 
section is for the right kidney anatomy. There are two diagrams on this form so 
the user can mark any abnormalities directly on the kidney diagrams. 



Lookup Fields 



Field Name 


List Name 


FlushSolution 


FlushSolution 


StorageSolution 


StorageSolution 



Heart, Lung, Pancreas and Liver Data 

Each one of these forms is used after the organ has been removed from the 
donor. They contain organ specific information concerning the removal and 
) storage of the organ. Each form is separate so that only the appropriate 

information gets sent to those whose request it. 



Lookup Fields 



Field Name 


List Name 


FlushSolution 


FlushSolution 


StorageSolution 


StorageSolution 



Intestine Data 

As of September 23, 1994, AMS has not received any intestine data information. 
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Tissue Data 

The Tissue Data form is arranged in a grid format. The user records which 
tissue was recovered and explains why it was not recovered in certain cases. 
The technician and tissue bank are recorded for each entry. 













mi 











Tissue Data 

OIS ID: 092094130712345 UNOS ID: HIT847 Donor Name: Bryan Lifley 
09/22/94 

Tissue Recovered Explanation, if No Technician Tisxue Bank 

Corneas/Eyes 

Skin \ 

Bone/Tendon r d r ^ r a 

Saphenous Vien tT „ r , r s r ^ 

Heart Valve \ \ 

Other \ 



General Notes 

The General Notes form is the area where users can record any other relevant 
information that is not covered in the forms of the Donor document This form 
will be the coordinator's note-taking area. 
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Organ Recovery 

Once the organs have been removed from the donor and placed with a recipient, 
the coordinator may elect to complete this form in order to have all of the 
necessary CDR data in one place. The Organ Recovery form is organized 
exactly like the last page of the CDR form. Basic questions are asked about the 
flush and storage solution and the disposition of the organ. Certain questions 
are also asked about the recipient and the recipient's center. 



Lookup Fields 



Field Name 


List Name 


TimeZone 


TimeZone 


LeftKI Recovered 


LeftKI Recovered 


RightKIRecovered 


RightKIRecovered 


LiverRecovered 


LiverRecovered 


IntestineRecovered 


IntestineRecovered 


PancreasRecovered 


PancreasRecovered 


HeartRecovered 


HeartRecovered 


LeftLungRecovered 


LeftLungRecovered 


RightLungRecovered 


RightLungRecovered 


RecvTeamProviderNum 


provider list 


FlushSolution 


FlushSolution 


StorageSolution 


StorageSolution 


PlacedBy 


PlacedBy 


Share Type 


ShareType 


DispositionCode 


DispositionCode 


DiscardReason 


DiscardReason 


RecipientCenterProvNum 


provider list 



Match Run Input 

The Match Run Input form is where a coordinator may edit Match Run 
information and request a new Match Run. This form contains all of the fields in 
the Match Run donor record used by the UNOS Match Run program. There are 
three important pieces to understanding how the Match Run process will work. 

• Match Run Input form 

• Match Run Gateway processes 

• Match Run Results form 

The Match Run Gateway and Match Run Results forms are discussed in later 
sections. 

The Match Run Input form displays the fields in the Donor document that are 
necessary to request a Match Run. The actual Match Run process does not 
start until the user initiates it by pressing the Request Match Run button located 
on this form. 

Match Runs can produce large and unsightly outputs, especially when an u O n 
donor is run for a kidney match. To avoid this problem, the user will enter the 
maximum number of lines to be produced for display. The default number will be 
300 lines. 
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Different Match Runs can be run if a center is a SEOPF member or a Region 6 
center. The Universal Donor Match will be the default Match Run type. If a 
center has access to run a SEOPF, SEOPF High Grade or a Region 6 match, 
then they will be prompted to select which match type they want to run. The 
SEOPF, SEOPF High Grade and the Region 6 matches are not used for extra 
renal matches. 

New Tray Result documents may be composed from this form if crossmatch 
results are available. Coordinators in centers that have individualized donor 
input variances will enter the appropriate information in a separate section. 

Currently, the center codes which have individualized donor input variances are: 



El 


NCNC 


Carolina Organ Procurement Agency 


EI 


NJTO 


New Jersey Tissue & Organ Share 


EI 


TXGC 


Gulf Coast Organ Procurement Agency 


0 


MWOB 


Midwest Organ Bank 


EJ 


TXSA 


South Texas Organ Bank 


EI 


LAOP 


Louisiana Organ Procurement Agency 


El 


OKxx 


All Oklahoma Centers 


El 


TXSB 


Southwest Organ Bank 


EI 


IAOP 


Iowa Statewide OPO 


El 


NEOB 


New England Organ Bank 


El 


VAxx 


All Virginia Centers 


EI 


OC 


Organ Center 



Each input variance is explained in structured English in the Appendix. This 
particular appendix needs to be thoroughly reviewed by UNOS IS staff members 
in order to ensure that the variance variable is filled in correctly. 

The Match Run donor record layout and field definitions are located in the 
appendix. This record is filled and then passed to the UNOS Match Run 
program through the VB/Notes Match Run Gateway. 
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Match Run Results Document 

Match Run Results are imported into the OIS system through the VB/Notes 
Match Run Gateway. Once the Match Run Results have been imported into the 
system and replicated to the coordinator's mobile computer, Match Run Result 
documents can be accessed through a View. 

The Match Run Results form consists of three main sections. The first section of 
the form contains identifying information about the Match Run. The second 
section of the form controls who can read and edit the form. The last section of 
the form contains the actual results of the Match Run. 



OIS 10: 092094130712345 UN OS ID: HCZ001 Match Run Number 1 
Organ: HR Date: 03/26/1994 rime: 10:31 

Reader Names: 




Author Names: 



VAFH, VAMC. John SmithA'AMV/UNOS, 
Jill King/VAFH/UNOS. Brian Johnson/VAMC/UNOS , 



Match Run Results 



Users may compose Fax and/or Pager Notification documents from the Match 
Run Results document by pressing the Fax or Page buttons. Both Faxing and 
Paging are explained in their corresponding sections within this document. 
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Tray Results Document 

A Tray Results document may be composed from the Match Run Input form in 
the Donor document. When the Trays Results document is composed, it inherits 
the OIS ID from the Donor document, and becomes a child to the parent Donor 
document. The donor name is retrieved from the parent Donor document for 
display purposes. Data entry on this form consists of selecting the tray name 
from a list, and entering values for each cell in the tray. Valid tray names are 
pulled from the ROP Tray Data database and cell values lists are stored in the 
OIS Data Validation database. The Tray Results document ensures that data 
entered in a Tray Result cell has a matching cell record in the ROP Tray Data 
database. 



Tray Results 

OIS ID: 1 23450920941 1 50 Donor Name: Bryan Lilley 

Tray Name: ' , 





A 


B 


C 


D 


E 


F 
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ROP Tray Data 




Data Validation Lists OIS User Information Center Information 




Description 

This database contains ROP Tray data to be used for data validation and to build 
crossmatch results files used in the Match Run process. Documents in this 
database are records in ROP Tray data files on the UNOS mainframe. This 
reference data is maintained on the mainframe; periodic updates to the Notes 
database will be necessary. The OIS system administrator must ensure that this 
reference database is in sync with the mainframe files. When users compose 
Tray Results documents, this database provides a valid list of tray names and is 
used to verify that data is entered in valid cells. 
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Tray Data File Record Layout 



rieia Name 


Length 


Columns 


unco 
MUSP 


4 


1-4 


AbO 


2 


5-6 


Recipient Name 


12 


7-18 


HICNUM 


10 


19-28 


WFI 1 MH 
VVCL-LIM^y 


Q 

o 


on o -i 


PK 


2 


32-33 


CR 


2 


34-35 


MONTH 


2 


36-37 


YEAR 


2 


38-39 



User Access 

All users will have Reader access to this database. This database may be 
viewed by users for reference, but it is primarily designed for system access. 
Because this data is maintained on the mainframe, users may not change or 
enter tray data through the OIS. 
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Match Run Requests 




Oala Validation Lists OlS User information Center Information 




Description 

The Match Run Request database holds donor information which is used for a 
Match Run request. When a coordinator initiates a Match Run from the field, a 
copy of the Donor document is sent to the Match Run Request database. This 
database is monitored by the VB/Notes Match Run Gateway process which 
initiates the Match Run process on the mainframe when a new request enters 
the database. Once the request has been processed, the Donor document will 
be moved to a Match Run Request Archive database. The structure of the 
Match Run Requests database is identical to the Donor Information database. 

User Access 

Only the Match Run Gateway and system administrators will have access to this 
database. 
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Fax/Page Phone Book 




OlS Data Validation 
LOOKUP.NSF 



ROP Tray Data 
TRAYS.NSF 



Oata Validation Lists 



Tray Dala- 





UNOS Name & 
Address Book 
NAMES.NSF 



OlS User Information 

i 

OlS Donor 
Information 
DONINFO.NSF 




Match Run Ouput 

1 



Tray 



UNOS Centers & 

Providers 
CENTERS.NSF 



Center Information 



Donor Information 



Match Run Requests | 
MATCH.NSF 




UNOS Mainframe 



Match Run 
-Process Commands 

Ma ten Run 
Output 



Match Run 
Gateway 



Donor Information 



Notes Database 



Description 



The Fax/Page Phone Book database contains information for people who have 
registered their fax machines or pagers with the OlS system along with their 
corresponding fax or pager PIN numbers. This information is collected through a 
Contact Document which consists of Center ID, Name, Fax Number, Pager PIN 
Number, Voice Number, and Comments. The people in the phone book may or 
may not be OlS users. This database is referenced when addressing a Fax or 
Pager Notification document, or may be used for reference by OlS users. 



User Access 



Once the document is created, it may be modified by the users in the Center ID 
group, the author of the document, or the Organ Center users. 
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PAGER NOTIFICATION 



The paging process allows OIS users to immediately notify people that donor 
information is available. There are three situations where users would use Pager 
Notification: 

• To notify another Notes user to replicate with the server to receive the latest 
donor information. 

• To notify another person to call into Phone Notes in order to request a fax of 
the latest donor information. 

• To notify another person that donor information has been faxed to them. 

A user may compose a Pager Notification document from the Donor Navigation 
form or from the Match Run Results form. 

A user may address the Pager Notification document by: 

• Selecting a person from a list of people with pagers from the Fax/Page 
Phone Book. 

• Selecting a center from a list of centers with pagers from the Center & 
Providers database. 

• Typing in the pager PIN number directly. 

A user enters a text message that may contain information such as recipient's 
name, recipient's position on the Match Run list and organ(s) available. The text 
message will be limited to the maximum number of characters supported by the 
SkyWord pager. 

Currently, the Notes Pager Gateway is only compatible with the Sky Tel Paging 
network. SkyTel is the leading provider of nationwide wireless messaging, 
reaching more than 90% of the US business population in over 1 1,000 cities and 
towns. SkyTel's SkyWord pager consists of an LCD screen. suitable for 
displaying information on the Pager Notification document. 
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The Pager Notification document is sent to the pager gateway. Once the 
document reaches the gateway, the following occurs: 

• The pager gateway will convert the data into a Page message. 

• The message is sent to SkyTel's central terminal. 

• SkyTel immediately broadcasts the message to the SkyWord pager that has 
the corresponding PIN number. 

• The LCD screen on the SkyWord pager will display who sent the page and 
their center, Date, OIS ID, and comments. 

%, I 

Lajjtop 

Paper Notification Form 



± 




SkyTel's 
Central 
Terminal 

I 

1 

Pager 
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FAXING DONOR INFORMATION 



Faxing donor information provides OIS users the ability to rapidly transmit 
information to people even if they are not a Notes client. Users may compose 
Fax documents from the Donor Navigation form or from the Match Run Results 
form. 

A user may address the Fax document by: 

1 . Selecting a person from a list of people with fax machines from the Fax/Page 
Phone Book. 

2. Selecting a center from a list of centers with fax machines from the Center & 
Providers database. 

3. Typing in the fax number directly. 

A user enters comments that may contain information such as recipient's name, 
recipient's position on the Match Run list and organ(s) available. This is stored 
in the comments section on the fax cover page. Users will also have the ability 
to select only the donor information forms that they want faxed. The selected 
forms will be pasted onto the Fax form. 











iFax Nome: | Sally Jones 
Fax Number: ' (703) 267-2222, 
From: Julian Marks at Center AMS 
Date: 09/22/9411:33:30 
Comments: ' John Smith 

3rd on list 

HR, 








Sender Phone Number " (703) 267-7015. 
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The Fax document is sent to the fax gateway. Once the document reaches the 
gateway, the following occurs: 

The fax mail is sent to a special Fax.NSF mailbox. 

A cover page for each fax will be created pulling information from the Fax 
document and the Donor document forms. 

The fax gateway continuously checks the Fax.NSF mailbox for fax mail. 

Once mail is found, the data is converted into a TIFF file for faxing. 

A Send request is placed in the GammaLink Pending queue. 

The GammaLink Queue Manager checks the Pending queue for Send 
requests. 

The data is sent over the phone lines to the receiving fax machine. 
The transmission is recorded in the GammaLink Sent queue. 
The transmission is added to the Fax Event Log. 

If sending the fax is unsuccessful, then the fax is returned to the sender with 
a message stating that the fax was undeliverable. 




Lapjtop 

Fax Form 

I 



FAX.NSF 



Undeliverable Fax 
Message 



OIS Notes Server 



Data converted into 
taxable format 



Send 
Request 




GammaLink Pending 




GammaLink Queue 


Queue 


► 


Manager 




GammaLink Sent 
Queue 



A user has the option of purchasing a fax modem for their computer and sending 
the information directly to another person. The user would print the donor 
information to the fax modem, enter the fax number, and fax it. Utilizing the fax 
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gateway does not require any additional hardware or software Notes Client 
workstations. 



LJNv_y^for Organ Sharing 



ams American Managortwnt System*. Inc. 



ORGAN INFORMATION SERVICE DESIGN DOCUMENT 



PHONE NOTES 



Once a center is notified that donor information is available, a user may call from 
any touch-tone telephone and have the donor information faxed back to them 
through Phone Notes. This expands the users of the OIS system to anyone with 
a touch-tone telephone. The caller does not need to be a Notes user. People 
who wish to use the OIS Phone Notes feature must register with UNOS to 
receive an OIS Phone Notes user number and Personal Identification Number 
(PIN). A user would call the server, log into the OIS system using their user 
number and PIN, listen to voice prompts, and enter the OIS ID and their fax 
number on a telephone keypad. The donor information would then be faxed 
back to them. 

When a user calls and enters an OIS ID, Phone Notes generates a Fax 
document with the donor information for the specified OIS ID. When a user keys 
in their fax number on their telephone keypad, the fax number is entered on the 
Fax document. When the user completes the call, the information is faxed to the 
user's fax machine, and an entry is made in the Phone Notes transaction log to 
record the event. 




Telephone 



Caller enters data 
on tetphone Keypad 



Phone Notes Server 



Fax form is 
generated 



The Fax Document 
is mailed to the Fax 
Gateway 



Fax Gateway 
transmits the fax 
back to the user 




Fax 
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MATCH RUN GATEWAY 




Data Validation Lists OtS User Information Center Information 




VB/Notes Background Process 

The VB/Notes Match Run gateway will be written in Visual Basic using the 
VB/Link for Lotus Notes VBX to read and write Notes data. The gateway will run 
in Windows and mimics a standard Notes client that accesses OlS Notes server 
over the UNOS Pathworks network. The gateway constantly loops, performing 
two basic functions: checking for new Match Run requests in the Match Run 
Request Notes database, and checking for Match Run Results from the 
mainframe gateway server program. 
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Processing Match Run Requests 

When the VB/Notes gateway detects a new Match Run request: 

1 . The VB/Notes gateway builds the Universal Donor Record based on the data 
contained in the Donor document residing in the Match Run Request 
database. 

2. If crossmatch results are to be used, a Crossmatch Results data file is 
created based on the Tray Results documents that have been composed for 
the donor. 

3. The VB/Notes gateway calls the mainframe gateway server program, 
passing the Universal Donor Record with the OIS ID appended to the end. 

4. The Match Run Request document is moved to a Match Run Request 
Archive database. 

5. An entry is made in the VB/Notes gateway log (Notes database). 

Process Match Run Results 

The VB/Notes gateway constantly monitors the shared network directory that the 
Match Run results will be written to. When a Match Run results file is located: 

1 . The Match Run results header is read to obtain key and identifying 
information. 

2. The Donor document associated with the Match Run results is located based 
on the OIS ID and a Match Run Results document is created as a child of the 
Donor document. 

3. If the import process is successful, the Match Run results file is deleted. 

4. If an error occurs, the Match Run results file is forwarded to the system 
administrators in an urgent mail message. 

5. An entry is made in the VB/Notes gateway log (Notes database). 

Error Trapping 

Any errors encountered by the VB/Notes gateway will be sent to the system 
administrator(s) in the form of an urgent mail message. The gateway will send 
status messages to system administrators at intervals defined by the 
administrator. 
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Match Run Results Headers 

Match Run Results files from the UNOS mainframe gateway server program will 
be separated by organ and will have the following header: 



Field Name 


Length 


Columns 


OIS ID 


15 


1-15 


UNOS ID 


6 


16-21 


Organ 


2 


22-23 


Date/Time 


12 


24-35 


Match Run Number 


2 


36-37 


Return Code 


2 


38-39 


Status Message 


n 


40- 



UNOS Development 

The changes which UNOS needs to incorporate into their mainframe system are 
outlined fin the following sections. These changes are needed in order for the 
Notes server and the mainframe system to share Match Run information. 
Without these updates to the mainframe system, the communication of Match 
Run output will not be possible. 

UNOS Mainframe Gateway Server Program 

The Mainframe Gateway Server program is the interface between the VB/Notes 
gateway and the Universal Donor Match Run processes. This program accepts 
Match Run requests from the VB/Notes Gateway, and writes the Match Run 
results to a shared network directory. Other requirements identified by UNOS for 
the Mainframe Gateway Server program are: 

• Establish a network link with the VB/Notes Match Run Gateway. 

• Command tracking. 

• Accept crossmatch results file from the VB/Notes gateway and write the 
crossmatch results file with long name (UNOS ID+DATE+TIME+\CSM') to 
USER$SEOPF:[MATCH_RESULTSTRAYS]. 

• Initiate OIS Universal Donor programs 
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M ! 




0 


0 


0|25-APR-9025-APR-90 i 




COIA ! 81303-321-6027 jN ! 




0 


0 


0I20-DEC-90 ! 
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COMH 


j 8j 800-448-4644 


Y 




c 


) 0| 0j27-NOV-91 




COPM 


! 8! 800-448-4644 


Y 




c 


I C 


I 0I19-JAN-90 


10 


CORS 


| 8i 800-448-4644 |Y j 3j S 


I C 


I 0I29-MAR-88 4-MAY-90 


8 


COSL 


i 8:800-448-4644 |Y 


2 


I 34i 11 


27 


.7-APR-86 4-MAY-90 i -4 


COUC 


i 8! 800-448-4644 


Y 


4 


11 C 


, C 


7-APR-8619-JAN-90 


10 


CTHH 


i 1|203-524-2256 


N 


4 


0 


2 


1 


7-APR-8610-DEC-88 




CTYN 


! 1 j 800-446-6362 


N 


4 


0 


0 


0 


7-APR-86 




DCCH 


2I202-223-8229 IN 


4 


0 


4 


1 


7-APR-8617-NOV-89 




DCGU 


2:202-223-8229 jN 


4 


18 


21 


42 


7-APR-8626-JAN-89 




DCGW 


2I202-223-8229 


N 


4 


5 


i 4 


15I7-APR-8614-DEC-88 




DCHU 


21202-223-8229 


N 


3 


3 


1 


7 


7-APR-8614-DEC-88 




DCTC 


2:202-223-8229 


N 




0 


1 


0 


10-FEB-8826-SEP-88 




DCWH 


21202-223-8229 


N 


! 3 


17 


28 


38 


7-APR-8614-DEC-88 




DCWR 


i 2:202-223-8229 


N 


3 


0 


13 


21 


7-APR-8628-OCT-88 




DEAI 


21302-651-4426 


N 


0 


0 


0 


0 


9-SEP-91 




DIAG 


11 1/1/01 


N . 4 


0 


0 


0 


7-APR-86 




FLAC i 3;813-253-2640 


Y 




0 


0 


0 


15-JAN-91 


0 


FLBG | 31305-463-3131 


N 


3 


0 


0 


0 


7-APR-86 




FLDB ! 3:305-896-6611 


N 


3 


0 


0 


0 


7-APR-86 




FLFH j 3|407-849-5912 


Y 


1 


91 


24 


32 


7-APR-86 6-AUG-90 


70 


FLFL ! 31904-395-0254 


Y 


1 


0 


0 


0 


25-AUG-8927-APR-92 


20 


FLFM 3:305-896-6611 


N 


3 


0 


0 


0 


7-APR-86 




FLFR | 3|813-939-1147 


Y 




0 


0 


0 


10-APR-91 


0 


FLJM I 3; 800-255-4483 


Y 


1 


120 


-12 


16 


^APR-86 3-DEC-89 


199 


FLJT j 3j 904-366-7900 


Y 




0 


0 


0 


29-MAR-89 


21 


FLMP ! 3i 800-255-4483 


Y 




0 


0 


0 


10-APR-92 3-DEC-89 




FLMV j 3j 305-325-7320 


N 


3 


0 


0 


0 


7-APR-86 




FLOM i 3|305-896-6611 


N 


3 


0 


0 


0 


7-APR-86 




FLSF 


3j81 3-253-2640 


Y 


1 


137 


99 


94 


7-APR-8620-DEC-89 


191 


FLSW 


31813-939-1147 


Y 




0 


0 


0 


10-APR-91 


8 


FLTG 


3j 8 13-253-2640 


Y 


1 


0 


0 


0 


7-APR-8615-JAN-91 


-83 


FLTO 


3! 904-887-7886 


N 


4 


1 


0 


0 


7-APR-8628-JAN-87 




FLTV 


3i81 3-253-0711 


N 


3 


0 


0 


0 


7-APR-86 




FLUF 


31800-535-4483 


Y 


1 


136 


73 


96 


7-APR-8631-JAN-90 


14 


GAEH 


3:800-544-6667 


Y 


2 


0 


0 


0 


7-APR-8621-DEC-89- 


4 


GAEM 


31800-544-6667 


Y 


3 


0 


7 


1 


7-APR-8613-JUN-89 


-5 


GAEL) 


3? 800-544-6667 


N 


3 


0 


0 


16 


20-SEP-88 




GAEX 


3 


404-321-4566 


N 


3 


0 


0 


0 


7-APR-86 




GAGM 


3 


404-321-4566 


N 


2 


0 


0 


0 


7-APR-8630-SEP-86 




GALL 


3 


800-544-6667 


Y 




0 


0 


0 


10-FEB-88 


0 


GAMC 


3 


706-721-3893 


Y 


1 


61 


38 


61 


7-APR-8618-DEC-89 


79 


GAPH 


3 


800-544-6667 


Y 




0 


0 


0 


9-AUG-88 9-AUG-88 


-5 


GASJ 


3 


800-544-6667 


N 




0 


0 


0 


14-OCT-8721-JUN-88 




GAUH 


3 


404-721-3893 


N 


4 


0 


0 


0 


27-JUN-88 




HIOP 


5 


808-599-7630 


N 




0 


0 


0 


19-AUG-92 




HISF 


5 


808-599-7630 


N 




0 


0 


0 


29-APR-87 




HOPE 


99 


519-663-3000 


N 




0 


0 


0 


5-DEC-86 




IAIM 


8j51 5-283-5744 


N 




0 


1 


0 


24-NOV-8717-SEP-88 




IAIV | 81319-356-7426 


N 


4 


0 


13 


0 


7-APR-8613-DEC-89 




IAMH 8:515-247-4261 i 


N 


4i 


0 


0 


0 


2-JUL-87 j ! 


IAOP ! 81319-356-7426 


N I i 


0 


0 


0I25-SEP-89 j 


ILCM ! 71312-880-3330 


N i 4! 


2 


01 0|7-APR-8621-AUG-89 I 
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ILCR 71312-543-6397 


N | 4j C 


) f 


> 1:7-APR-8610-OCT-88 j 


ILED j 71312-649-3338 


N 


4_4| — C 


) C 


> 0|7-APR-86 j 


ILEH 


71312-492-2000 


N 


I c 


I C 


) 0 


18-DEC-8718-DEC-87 ! 


ILEN 


7j312-649-3338 


N 


A 


\ C 


I c 


i a 


7-APR-86 I 


ILIP 


7j 31 2-431 -3600 


N 




c 


I 1 


' 0 


21-DEC-8719-FEB-90 j 


ILLU 


71708-216-8000 


N 


A 


\ c 


2 


1 


7-APR-8625-FEB-92 ' 


ILLV 


7|312-649-3338 


N 


A 


0 


C 


0 


7-APR-86 ' 


ILMM 


71217-782-5880 


N 


A 


0 


G 


0 


7-APR-8621-AUG-89 


~i 


ILMN 


71217-782-6080 


N 


A 


0 


0 


0 


7-APR-86 




ILNM 


7; 3 12-908-8900 


N 


A 


0 


17 


20 


7-APR-86 3-FEB-92 




ILPL 


7j312-266-5888 


N 


4 


0 


0 


5 


7-APR-8629-DEC-89 




ILSF 


7|309-655-2000 


N 


4 


0 


0 


0 


7-APR-8621-AUG-89 ! 


ILSM 


71312-649-3338 


N 


4 


0 


0 


0i7-APR-86 I 


ILUC 


7|3 12-702-3000 


N 


4 


0 


0 


0 


20-JAN-92 ! 


ILUI 


71312-996-6771 


N 


4 


0 


10 


0 


7-APR-8621-AUG-89 




ILVA j 71312-531-3000 


N 




0 


0 


0 


31-AUG-8931-AUG-89 




INCI i 10 


317-924-8888 


N 


3 


0 


0 


0 


7-APR-86 




INDV 


10 


317-924-8888 


N 


3 


0 


0 


0 


7-APR-8619-NOV-86 




INEV 


10 


317-924-8888 


N 


3 


0 


0 


0 


7-APR-86 6-NOV-87 




INFW 


10 


317-924-8888 


N 


3 


0 


0 


0 


7-APR-86 6-NOV-87 




INHA 


10 


317-924-8888 


N 


3 


0 


0 


0 


7-APR-86 9-JUL-86 




INIM 


10 


317-924-8888 


N 


1 


22 


6 


7 


7-APR-8629-DEC-89 




INIU 


10 


317-924-8888 


N 


3 


7 


0 


6 


7-APR-8614-SEP-89 




INIV j 10 


317-924-8888 


N 


3 


0 


0 


0 


7-APR-86 8-JUL-87 




INLA 


10 


317-924-8888 


N 


3 


0 


0 


0 


7-APR-86 6-NOV-87 




INLF 


10j31 7-924-8888 


N 


3 


0 


0 


0 


7-APR-8614-DEC-87 




INLH 


101317-924-8888 )N 


4 


0 


0 


0 


7-APR-8615-OCT-86 




INMU 


101317-924-8888 


N 


3 


0 


0 


0 


7-APR-86 6-NOV-87 




INOP 


101317-924-8888 


N 




0 


0 


0 


23-DEC-87 j 


INSB 


10|31 7-924-8888 


N 


3 


0 


0 


0 


7-APR-86 6-NOV-87 | 


INSV 


10 


317-924-8888 


N 


3 


0 


0 


0 


7-APR-86 6-NOV-87 


I 


INTE 


10 


317-924-8888 


N 


3 


0 


0 


0 


7-APR-86 8-JUL-87 




INVA 


101317-924-8888 


N 


3 


0 


0 


0|7-APR-86 




INVI 


10j 3 17-924-8888 


N 


3 


0 


0 


0|7-APR-8614-DEC-87 




KSFT 


8i 800-366-6791 


N 


4 


0 


0 


0|7-APR-86 




KSFW 


81800-366-6791 


N 


4 


0 


0 


0 7-APR-8612-DEC-89 




KSUK 


81800-366-6791 


N 


4 


0 


0 


0I7-APR-8629-MAY-90 




KYHH 


111800-525-3456 


Y 




0 


0 


0 21-JUL-92 




KYJH 


11 


800-525-3456 


Y 


1 


46 


38 


40 7-APR-8615-OCT-90 




KYKC 


11 


800-525-3456 


N 


4 


0 


0 


0 30-SEP-8730-SEP-87 




KYKY 


11 


800-525-3456 


Y 


1 


12 


3 


3|30-SEP-87 7-FEB-89 


48 


KYUK 


11 


800-525-3456 


Y 


1 


0 


0 


0I7-APR-86 1-DEC-87 


20 


KYUL 


11 


600-525-3456 


N 


3 


0 


0 


0 7-APR-86 1-DEC-87 




KYWK 


11 


502-589-4148 


N 


4 


0 


0 


0 7-APR-86 




LANO 


3 


504-464-3898 


Y 


1 


22 


20 


53 7-APR-86 1-SEP-91 


5 


LAOF 


3 


504-842-3838 


Y 


1 


3 


5 


1 1 7-APR-86 2-NOV-89 


21 


LAOP 


3! 


504-837-3355 


Y 




0 


0 


0 17-MAR-88 


17 


LASB 


3 


504-837-3355 S 


N 


4 


0 


2 


0 7-APR-8622-NOV-89 




LASM 


3 


318-227-4715 


Y 


4 


0 


0 


0I7-APR-86 2-NOV-89 


10 


LASU ! 


3 


318-226-3589 


Y 


1 


14 


28 


17|7-APR-86 2-NOV-89 


-4 
2 


LATU t 


3 


504-588-5303 


Y | 1 


16 


16 


23 7-APR-8622-JUL-89 i 


LAWK | 3:318-226-3589 


N i 


0| Oi 0I26-JUL-89 5-OCT-89 ! 
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MABI i 1 1800-446-6362 


N 




1 ( 


) ( 


31 < 


) 7-APR-86 




MABS ! Ij 800-446-6362 


N 




( 


) ( 


3 ( 


) 20-OCT-88 




MABU j 1|800-446-6362 


N 


i 


I ( 


) ( 


) ( 


) 7-APR-86 




MABV j 1:800-446-6362 


N | i 


1 ( 


) ( 


) ( 


) 7-APR-86 




MACH j 1 i800-446-6362 


N i t 

1 


\ C 


) 1 1 


7-APR-8631-MAR-89 




MAHS i 1)800-446-6362 


N 


A 


1 c 


) o| c 


J7-APR-86 




MALC | 11800-446-6362 


N 


A 


\ c 


) oj c 


) 7-APR-86 




MAMG j 1 1 800-446-6362 . 


N 


A 


\ c 


I 3! 1 7-APR-8610-JUL-89 




MANM 1j 800-446-6362 




A 


r c 


0| 0 7-APR-86 




MAPB 1|800-446-6362 


N 


4| ' C 


0| 0j7-APR-86 




MAUM j 1 j 800-446-6362 


in 


4| C 


0 0 7-APR-86 




MDBC 2:301-328-3626 


N 
in 


2j C 


Oj 0|7-APR-8612-NOV-90 




MDJH j 2|301-328-3626 


M 
in 


£ 


62 


47 59 7-APR-8612-NOV-90 




MDPC j 21301-528-3626 


N 

IN 




0j 0| 0 12-NOV-9012-NOV-90 




MDUM I 2; 301 -328-3626 


M 
In 




0 0| 1|7-APR-8612-NOV-90 




MEMC j 1| 800-446-6362 


In 


A 


0 oj 0j7-APR-86 




METR | 1|514-527-0047 


In 




0 oj 0|5-DEC-86 




MIAA j 101- - 


In 




0| 0| 0j27-AUG-86 




MIBH j 101313-973-1577 


M 

IN 


A 


Oj 0 


0I7-APR-86 




MICH ! 10j 31 3-973-1 577 


M 

IN 


A 
H 


0 0 


017-APR-86 




MIHF i 10,313-973-1577 


IN 


A 


0| 2 


5 


7-APR-8628-DEC-BQ 




MIHH 


10|313-973-1577 


IN 




0| 0! 0 


25-OCT-90 




MIHM 


10| 31 3-973-1 577 


IN 


4 


ol o! 0 


7-APR-86 




MIKZ 


10|313-973-1577 


N 

IN 


4 


0 4 


0 


7-APR-8610-JUL-89 




MIMC 101313-973-1577 


N 

IN 


4 


0 1 


1 


7-APR-8610-MAY-89 




MIMS | 10 


313-973-1577 


N 


4 


0 0 


0 


7-APR-86 




MIOP i 10 


3139731577 


N 








20-OCT-91 




MISH j 10 


I" * 


N 


4 


o| 0 


0 


7-APR-86 




MISJ j 10j 31 3-973-1 577 I 


N 




0 


0 


0 


2-JUL-90 2-JUL-90 




MISM j 101313-973-1577 


N 


4 


0 


0 


0 


7-APR-86 




MITS | 10i 31 3-973-1 577 


|S| 


4 


2 


0 


0 


7-APR-8613-OCT-86 




MIUM 


10 


313-973-1577 


N 


4 


0 


1 


6 


7-APR-8611-MAR-88 




MIVA 


10 


313-973-1577 


N 


4 


0 


0 


0 


7-APR-86 




MIWS i 10(313-973-1577 


N 


4 


0 


0 


0 


7-APR-86 




MNAN 


7 


612-874-5700 


ist 




0 


0 


0 


29-SEP-86 3-OCT-88 




MNHC 


7 


612-347-5850 


N 


4 


0 


0 


0 


7-APR-86 3-OCT-88 




MNMC 


7 


507-284-2511 


N 


4 


0 


0 


0 


7-APR-86 3-OCT-88 




MNMG 


7 


612-347-5850 


N 


4 


0 


0 


0 


7-APR-86 




MNMV 


7 


800-247-4273 


N 


4 


0 


0 


0 


7-APR-86 




MNOP 


7 


800-247-4273 


N 




0 


0 


0 


2-JUN-8829-JAN-92 




MNSM 


7 


507-284-2511 


N 




0 


0 


0 


8-NOV-90 




MNTL 


7 


612-625-4979 


N 




0 


0 


0 


29-DEC-88 




MNUM 


7 


800-247-4273 


N 


4 


0 


3 


7 


7-APR-86 3-DEC-89 




MOBH 


8 


800-333-6432 


N 


4 


6 


-2 


2 


7-APR-86 5-DEC-89 




MOCG 


8 


800-333-6432 


N 




0 


0 


0 


27-NOV-90 




MOCH 


8 


800-333-6432 


N 


4 


0 


1 


1 


7-APR-8619-SEP-86 




MOCM 


8j 800-366-6791 












30-AUG-9106-SEP-91 




MODU 


8! 800-333-6432 


N 




0 


0 


0 


10-DEC-8722-JUN-89 




MOJH 


8|314-362-1242 


N 


4 


0 


0 


0 


7-APR-86 




MOLH ! 


8|800-366-6791 


N 


4 


0 


0 


0 


7-APR-8629-MAY-90 i 


MOMA ! 


8 


800-333-6432 


N 




0| 0 


0 


24-MAR-8815-JUL-88 


MOMM i 8< 800-366-6791 |N 




01 0 


0I6-JAN-88 i 
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MORE i 8|416-595-3587 ,N 


i ! 


1 ( 


) 0I5-DEC-86 5-MAR-87 




MORH j 81800-366-6791 IN 


I 4i oj c 


) ( 


) 7-APR-8629-MAY-90 




MOSL j 8| 800-333-6432 ;N 


! 4| ( 


) C 


) c 


)7-APR-8615-JUL-88 




MOTS 


j 81519-663-3000 IN 


! C 


) c 


I c 


) 5-DEC-86 




MOUM 


j 8.1800-366-6791 jN 


A 


i c 


) 1 


1 


7-APR-8626-AUG-86 




MSUM 3:601-984-1000 


Y 


1 


71 


45 


5C 


I 7-APR-8628-SEP-89 


127 


MWOB ! 8:800-366-6791 


N 


A 


1 


c 


c 


1 7-APR-86 9-NOV-89 




MWWL 


i 7| 800-446-2726 


N 




! Oj C 


c 


1 23-JUN-89 I 


NCBG 


11j800-833-3002 


Y 




! 8 4 


1 


7-APR-8615-DEC-89 


35 


NCBH 


111919-748-4563 


N 




8 0 


0 


7-APR-8628-DEC-89 




NCCM 


111704-355-2000 


Y 




42 36 


67 


7-APR-8631-AUG-90 




NCCP 


j 11 j919-752-5480 


N 




31 34 


80 


7-APR-8616-DEC-89 




NCDU 


I 11 1919-752-5480 


Y 




0 0 


0 


7-APR-8630-DEC-87 


20 


NCDV 


! 111919-752-5480 


IN 




o| 0 


0 


7-APR-86 




NCEC i 1 1 


919-752-5480 


Y 




Oj 0 


0 


7-APR-8630-DEC-87 


20 


NCMH i 11 


919-752-5480 !Y 




0| 0 


0 


7-APR-8630-DEC-87 


CJ\J 


NCNC I 11 


919-752-5480 jY 




i 87 71 


71 


29-JUN-8810-JAN-89 




NCRC i 11 


800-446-2726 !N 




! 0 0 


0 


25-MAR-88 




NDDH i 7701-234-6000 jN 




0 0 


0 


I8-JUN-89 2-NOV-89 




NDMC | 7j 701 -224-6000 |N 




ol 0 


0 


14-OCT-8830-NOV-88 




NDSL j 7|701 -234-6000 


N 




0 0 


0I6-DEC-89 




NDTB j 71701-222-5200 


N 


4 


0 0 


0 


19-JAN-9026-MAR-90 




NDTC | 71701-224-6000 


N 




0 


0 


0I19-JAN-90 




NDTS i 71701-234-6000 


N 




0 


0 


0 


18-OCT-89 




NEBM j 8! 402-553-7952 


N 




0 


0 


0 


7-FEB-89 




NECM j 8j 402-553-7952 


N 




0 


0 


0 


7-FEB-89 




NEOB I 11800-446-6362 


N 


4 


0 


-3 


0 


7-APR-8630-DEC-88 




NEOR 


8! 402-553-7952 jN 


4 


0 


0 


0 


7-APR-86 




NEOX 


1| 800-446-6362 


N 


3 


0 


0 


0 


19-MAY-86 




NESJ 


8| 402-553-7952 


N 


4 


0 


0 


0 


7-FEB-89 7-FEB-89 




NEUN 


81402-553-7952 


N 




0 


0 


0 


7-FEB-89 




NHDH 


11800-446-6362 


N 




0 


0 


0 


10-AUG-9230-DEC-88 




NJBI 


2j 800-54 1-0075 


N 


3 


34 


1 


44 


7-APR-8626-MAR-90 




NJLL 


2| 609-428-5999 


N 


3 


9 


8 


8 


7-APR-8628-NOV-89 




NJSB 


21800-541-0075 


N 


4 


24 


23 


20 


7-APR-8620-APR-90 




NJSN 


2 


201-379-4535 


N 




0 


0 


0 


12-DEC-88 




NJTL 


2 


800-541-0075 


N 




0 


0 


0 


12-DEC-8818-JUN-90 




NJTO 


2 


800-541-0075 


N 




0 


0 


0 


10-APR-9018-JUN-90 




NJUH 


2 


800-541-0075 


N 




0 


0 


0 


13-FEB-8926-MAR-90 




NMAQ 


5 


505-843-2111 


Y 


1 


16 


15 


24 


7-APR-8631-OCT-91 


27 


NMOP 


5 


505-843-7672 


Y 




0 


0 


0 


21-AUG-87 


31 


NMPH 


5 


505-841-1234 


N 




0 


0 


0 


5-SEP-8631-OCT-91 




NORS 


8 


402-553-7952 


N 




0 


36 


0 


4-SEP-8726-JUL-89 




NVHH 


5 


702-796-9600 


N 




0 


0 


0 


3-JUL-90 3-JUL-90 




NVLV 


5 


702-796-9600 


N 




0 


0 


0 


9-OCT-87 3-JUL-90 




NVUM 


5 


702-796-9600 


N 




0 


0 


0 


28-FEB-90 3-JUL-90 




NYAM 


9i518-381-7111 


N 


4 


0 


0 


0 


7-APR-86 




NYAP 


9 


518-381-7111 


N 




0 


0 


0 


12-DEC-89 




NYBC 


9 


716-883-0003 


N 




0 


0 


0 


9-JAN-91 9-JAN-91 




NYBU ] 9j 7 16-883-0003 


N 


4j 0 


0 


0 


7-APR-86 9-JAN-91 




NYCL | 91212-870-2240 


N 


! o 


0 0 


20-DEC-89 | 


NYCO ! 9i 2 12-54 1-8060 


N 


! o! ol o 


20-JUL-90 i 
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Center Data File 



NYCP 

IX 1 V-M 


i 91212-870-2240 


N | 4 


0! 4 


2i7-APR-8630-MAY-90 j 


NYDP 


j c 


1 718-234-9700 


N j 


^ °j ? 


C 


1 13-NOV-87 




NYD55 


! £ 


1212-870-2240 


k 1 

N 


1 A 

A 


0! e 


2 


7-APR-86 1-MAY-88 




NYPC 

IX I L-V^ 


I £ 


I 716-883-0003 


Kl 

N 




0 


0 


0 


j9-JAN-91 9-JAN-91 | 


NIYF1 

IX 1 IV. 


1 £ 


I 716-275-2729 


N 




0 


c 


0I22-APR-9222-APR-92 




NYIL 


£ 


1 212-870-2240 


N 




0 


0 


0i26-OCT-891 2-DEC-89 




NYMA 

ix i ivir^ 


9j 2 12-870-2240 


N 


A 


0 


r~ 0 


0 


7-APR-86 6-MAR-87 




NYMH 

IX 1 IVII I 


9,212-241-7344 


N 




0 


0 


0 


28-JUN-8929-JUN-89 




NYMS 


91212-870-2240 


Kl 


A 


0 


1 


1 


7-APR-8610-OCT-86 




NYNIY 


91212-870-2240 


Kl 

N 


A 


0 


28 


9 


j7-APR-8610-OCT-88 




NYRT 

ix i n i 


91212-870-2240 


Kl 

N 




0! 0 


0 


1-FEB-88 




1 X 1 ou 


9 5 16-689-8333 


Kl 

N 




Oj 0 


0 


i7-APR-8621-MAR-89 




IX 1 uL 


9| 2 12-870-2240 


Kl 

N 


4 


0 


0 


0 


7-APR-86 




Ix T OIVI 


9; 7 16-275-2729 


Kl 

N 




0 


0 


0 


24-APR-9222-APR-92 




IX I Uv 


91212-870-2240 


N 




0 


0 


0 


1-NOV-88 




MYI IM 

Ix T Ulvl 


9i 3 15-464-5540 


N 


4 


0 


0 


0 


7-APR-86 2-DEC-89 




Ix T VVO 


9|212-870-2240 


N 




0 


0 


0 


18-JUL-8931-OCT-89 




MYWM 
Ix T VVIx 


9 


716-883-0003 


N 


4 


0 


-9 


0 


7-APR-8624-OCT-89 




VJUU 1 


99 


800-292-9537 


N 


4 


oj 0 


0 


21-APR-92 






99i 800-292-9537 


N 


4 


i 




30-APR-92 






99! 800-292-9537 


N 


4 


oj 0 


0 


30-APR-92 






99I800-292-9537 


N 


4 


u 


U 


0 


30-APR-92 






99! 800-292-9537 


N 


4 


n 
u 


n 


0 


30-APR-92 






99; 800-292-9537 


N 


4 


n 
u 


u 


0 


30-APR-92 






99! 800-292-9537 


N 


4 


0 


0 


0 


30-APR-92 




OC08 


99! 800-292-9537 


Kl 

N 


4 


0 


0 


0 


30-APR-92 




OC09 


99; 800-292-9537 


Kl 

N 


4 


0 


0 


0 


30-APR-92 




OC10 


99j 800-292-9537 


Kl 

N 


4 


0 


0 


0 


30-APR-92 




0C11 


991 800-292-9537 


Kl 

N 


4 


0 


0 


0 


30-APR-92 




OC12 


99! 800-292-9537 


Kl 

N 


4 


0 


0 


0j30-APR-92 




OC13 


99! 800-292-9537 


Kl 

N 


4 


0 


0 


0|30-APR-92 




OC14 I 99! 800-292-9537 


K 1 

N 


4 


0 


0 


0|30-APR-92 




OC15 I 


99:800-292-9537 


Kl 


4 


0 


0 


0 


30-APR-92 




OHAC 


101216-791-5433 


Kl 


4 


0 


4 


1 


7-APR-8612-FEB-88 




OHCA 


10 


216-791-5433 


Kl 

N 


4 


0 


0 


0 


7-APR-8616-MAY-88 




OHCC 


10 


216-791-5433 


Kl 

IM 


4 


0 


12 


4 


7-APR-8625-SEP-89 




OHCD 


10 


614-263-5667 


Kl 




0 


0 


0 


8-JUN-88 




OHCH 


10 


614-263-5667 


IM 


4 


0 


0 


0 


7-APR-86 9-FEB-87 




OHCM 


10 


513-558-5000 


Kl 
Ix 




0 


0 


0 


11-OCT-9020-FEB-91 




OHCO 


10 


419-893-4891 


Y 
T 


1 


17 


8 


10 


7-APR-8631-MAY-89 




OHCV 


10 


216-791-5433 


M 
Ix 


A 
H 


0 


0 


0 


7-APR-8630-AUG-86 




OHCW 


10 


800-558-5433 


Ix 


A 
H 


0 


0 


0 


7-APR-8614-DEC-87 




OHDC 


10 


614-263-5667 


Ix 


A 
H 


0 


0 


0 


7-APR-86 2-DEC-86 




OHDN 


10 


614-263-5667 


N 


4 


0 


0 


0 


7-APR-86 




OHLB 


10 


216-791-5433 


N 




0 


0 


0 


26-OCT-87 




OHLC 


10 


513-223-1606 


Y 




0 


0 


0 


8-MAR-90 


38 


OHLI 


10 


614-263-5667 


N 


4 


0 


0 


0 


7-APR-86 3-DEC-86 




OHLM 


10 


419-893-4891 


N 


1 


0 


0 


0 


7-APR-8622-MAR-88 




OHLP 


10 


614-263-5667 


N 




0 


0 


0 


19-JUN-89 




OHMC 


10j614-263-5667 


Y 


4 


0 


0 


0 


7-APR-86 2-DEC-86 


0 


OHMG | 


101800-558-5433 


N 


4 


0 


0 


0 


7-APR-8614-DEC-87 




OHMI I 101614-263-5667 


N 


4 


0 


0 


0 


7-APR-86 
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Center Data File 



IOHMN 



OHMS 



OHMV 



OHOC 



OHOR 



OHOU 



OHPH 



OHRH 



OHSE 



OHSP 



OHSV 



OHTC 



IOHTH 



10161 4-263-5667 



101 800-558-5433 
10!51 3-223-1 606 



101614-591-68 1 



10 



216-000-0000 



10 614-263-5667 



10i614-263-5667 



N_ 

IOHPM j 10i61 4-263-5667 !N 



N 



N 



N 



N 



N 



10-614-263-5667 IN 
10:216-791-5433 IN 



10|61 4-263-5667 |N 



36 



4 



101419-893-4891 !N 



l6ts 13-558-5000 N 



10|419-893-4891 
101614-263-5667 



N 



16 



1 



0|7-APR-86 2-DEC-86 



34 
0 



7-APR-8614-DEC-87 



7-APR-86 4-DEC-89 



16-NOV-8930-JAN-90 



7-APR-86 



0,7-APR-86 6-DEC-89 



017-APR-8626-MAY-89 



0 7-APR-86 



0 7-APR-86 



0|27-SEP-8823-APR-90 



0 7-APR-86 



0|7-APR-8622-MAR-88 



11-OCT-90 



0 7-APR-86 



25 



OHTL 



N 



017-APR-86 2-DEC-86 



|OHUH 


101216-791-5433 


M 




r 
v, 


J I 


c 


t 24-PtD-8824-JAN-89 


i 

i 


OHZA 


! 10j614-263-5667 


N 
1 'i 


I 


L f 


1 c 




» 7-APH-86 9-FEB-87 




OKBC 


! 4|405-840-5551 


N 






' 1 


c 


* lo-hbb-o/ 1 1-JAN-89 




OKCM 


41405-840-5551 


N 


A 
* 


I f 
r VJ 




1 r 


7 ADD OC11 li iki o~y 




JoKHM 


j 41405-840-5551 


N 


I 


I c 


1 

1 


1 

i 


7-APD fi£ A ADD OO 




OKMD 


! 4|405-840-5551 


Y 


i 


C 


VJ 


VJ 


7-APR-flfi 1 II IM P.7 


1 


OKMH 


4|405-271-4438 


N 


4 


0 


0 


n 
\j 


7-APR-flfi 
/ nrn ou 




OKOP 


4i405-840-5551 


N 




0 


0 


n 

V 






OKOV 


4j405-840-5551 


N 


4 


0 


7 


0 


7-APR-861 3-APR-flQ 




OKSA 


41405-840-5551 


Y 


1 


7 


7 


7 


7-APR-861 4-SFP-R7 


.A 


JOKTH 


4 918-584-1351 


N 


4 


0 


0 


0 


7-APR-86 




ORUO 


6 503-494-8555 


N 


4 


0 


1 


0 


7-APR-8630-APR-90 




PAAE 


21800-543-6391 


N 


4 


0 


0 


0 


7-APR-86 




IPAAG 


2!800-366-6777 


N 


3 


0 


-1 


0 


26-OCT-8720-DEC-89 




PACH 


2j 800-366-6777 


N 




0 


0 


0 


27-OCT-8718-AUG-89 




PACP 


21800-543-6391 


N 




0 


0 


0 


28-SEP-8813-JAN-89 




PADV 


2! 800-543-6391 


N 




0 


0 


0 


21-FEB-88 




PAGM 


2,800-543-6391 


N 


4 


0 


1 


0 


7-APR-8623-JAN-89 




PAHE 


2 


800-543-6391 


N 


4 


0 


20 


11 


7-APR-8628-DEC-88 




PAHM 


2 


800-543-6391 


N 


4 


0 


0 


0 


7-APR-86 




PALV 


2 


800-543-6391 


N 




0 


0 


0 


8-MAY-91 




PAPT 


2 


800-366-6777 


N 


3 


0 


18 


68 


7-APR-86 5-JAN-90 




PASC 


2 


800-543-6391 


N 


4 


0 


6 


4 


7-APR-8616-AUG-88 




PATF 


2 


800-366-6777 


N 




0 


2 


0 


26-OCT-8717-AUG-89 




PAT J 


2 


800-543-6391 


N 


4 


0 


-9 


6 


7-APR-86 9-MAR-89 




PATU 


2 


800-543-6391 


N 




0 


0 


0 


7-MAY-87 




PAUF 


2 


800-543-6391 


N 


4 


0 


0 


0 


7-APR-86 




IPAUP 


2 


800-543-6391 


N 


4 


0 


25 


0 


7-APR-8623-JAN-89 




PRSJ 


3 


809-758-2000 


N 


4 


0 


1 


4 


7-APR-8614-DEC-87 




PRUA 


3 


809-758-7575 


N 


4 


0 


0 


0 


7-APR-86 




PRVA 


3 


809-758-2000 


N 




0 


0 


0 


23-SEP-86 




ROPA 


5 


310-825-7651 


N 


4 


1 


9 


27 


7-APR-86 5-NOV-91 




SCDF 


11 




N 




0 


0 


0 


25-AUG-86 




SCKC 


11 




N 




0 


0 


0 


25-AUG-86 




SCMU 


11 


803-724-5563 


Y 


-it 


10 


5 


17 


7-APR-8617-OCT-89 -29 


SCOP 


11 


803-724-5563 


N 


i 


01 0 


0 


5-APR-88 
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Center Data File 



scwc 


4_i 


1 - - 


N 




< 


) ( 


) 0j25-AUG-86 




SEOP 


! 2 


I 804-755-1615 


N 




1 ( 


) ( 


) 0 7-APR-86 3-OCT-88 




TESQ 


I 


I 800-555-5555 


N 




( 


) ( 


) ( 


3 16-OCT-87 




TNBM 




I 901-522-5055 


N 




( 


) ( 


) ( 


3 3-MAR-88 




TNDC 


! r 


I 615-327-2247 


Y 


1 


3< 


) 2( 


) 2! 


3 7-APR-8620-DEC-90 




TNDS 


! 11 


I 615-327-2247 


Y 




( 


) ( 


) ( 


3 2-JUN-8811-JAN-91 


43 


TNEM 


: 11 


615-757-1006 


Y 




( 


) C 


> 0j19-OCT-89 


34 


TNET 


11 


615-929-1141 


Y 




C 


> C 


> 0|8-SEP-88 


137 


TNJC 


11 


615-926-3112 


Y 








I22-AUG-9008-JUL-91 


113 


TNMH 


11 


901-528-5923 


IN 




c 


I C 


I o| 1 4-OCT-871 4-OCT-87 




TNMS 


11 


901-577-5923 


Y 




c 


G 


I 0 3-JAN-91 


-32 


TNNV 


11 


615-321-3003 


Y 


1 


14 


10 


7|7-APR-8614-NOV-89 


0 


TNPV 


11 


615-321-3003 


Y 




G 


G 


0 23-JUN-89 2-NOV-89 


-23 


TNST 


11 


615-327-2247 


Y 


1 


0 


G 


r 
t 


\ 7 ADD ocon II II on 


13 


TNTN 


11 


615-327-2247 


Y 




0 


0 


L 


07 HPT OOH -i 1AM CI 


43 


TNUK 


11 


615-544-9881 


Y 


1 


35 


14 




7 add qco7 ncr on 


-8 


TNUT 


11 


901-528-5923 


Y 


1 


48 


29 


Of 


7 ADD QC c | AM OA 

/-Mrn-oo o-JAIM-yu 


-2 


TNVU 


11 


615-321-3003 


Y 


1 


17 


8 


I D 




-50 


TOFA 


5 


619-933-3333 


N 


4 


0 


0 


n 
u 


7-APR-flfi 




TXAD 


4 


512-459-4848 


N 


4 


0 


0 


n 


7-APR-fifi1 ?-Al Jf5-Q9 




TXAV 


4 


512-732-9612 


N 


4 


0 


0 


o 


7-APR-86 




TXBC 


4 


512-732-9612 


Y 


3 


0 


2 


4 


7-APR-861 4-DPC-88 


-4 


TXBU 


4 


214-821-1910 


N 




0 


0 


o 


29-DEC-88 




TXCM 


4 


214-821-1910 


N 


4 


0 


1 


o 


7-APR-86 3-JAN-90 




TXCT 


4 


512-459-1111 


N 


0 


0 


0 


0 


6-NOV-90 




TXDR 


4 


512-732-9612 


N 


4 


0 


0 


0 


7-APR-86 




TXEA 


4 


512-732-9612 


N 


4 


0 


0 


0 


7-APR-86 J 




TXEP 


4 


800-666-1884 


N 




0 


0 


0 


26-FEB-90 




TXFW 


4 


817-870-0060 


N 


4 


0 


0 


0 


7-APR-86 4-MAR-87 




TXGC 


4 


713-799-9115 


N 




0 


0 


0 


16-OCT-8714-JAN-88 




TXHD 


4 


512-732-9612 


N 




0 


0 


0 


6-MAR-90 




TXHH 


4 


713-799-9115 


N 


3 


3 


10 


10 


7-APR-8613-JAN-88 




TXHI 


4 


713-799-9115 


N 




0 


0 


0 


31-MAR-8714-JAN-88 




TXHS 


4 


512-732-9612 


N 




0 


4 


8 


25-JAN-9025-JAN-90 




TXHT 


4 


214-821-4284 


N 


4 


0 


0 


0 


7-APR-86 




TXJL 


4 


409-762-2560 


N 




0 


0 


0 


30-AUG-8912-OCT-89 




TXJS 


4 


409-762-2560 


N 


4 


0 


1 


1 


7-APR-8610-OCT-86 




TXKD 


4 


512-732-9612 


N 


4 


0 


0 


0 


7-APR-86 




TXLA 


4 


512-732-9612 


N 


4 


0 


0 


0 


7-APR-86 




TXLG 


4 


806-744-4499 


N 




0 


0 


0 


14-APR-88 9-DEC-91 




TXLM 


4 


806-744-4499 


N 




0 


0 


0 


2-JUL-90 9-DEC-91 




TXMC 


4 


214-821-1910 


N 


4 


0 


-5 


0 


7-APR-86 5-JAN-90 




TXMH 


4 


713-799-9115 


N 


3 


3 


3 


35 


7-APR-8614-DEC-88 




TXPM 


4 


214-821-1910 


N 


4 


0 


11 


3 


7-APR-8624-MAR-87 




TXSA 


4 


512-732-9612 


N 


4 


0 


0 


0 


11-SEP-86 




TXSB 


4, 


214-821-1910 


N 




0 


0 


0 


8-SEP-88 




TXSH 


4, 


512-732-9616 


N 


4 


0 


0 


0 


7-APR-86 




TXSM 


4! 


315-546-6009 


N 




0 


0 


0 


29-MAR-8829-MAR-88 




TXSP 


a: 


214-821-1910 I 


M 


4 


0 


0 


0 


7-APR-86 




TXSR 


Ai 


512-732-9612 I 


M 


4 


0 


0 


0 


7-APR-86 i 




TXST 


A I 


512-732-9612 ' 


/ 


4 


0 


0 


0 


7-APR-86 i 


0 


TXSW 4 ; 


214-821-1910 I 






0 


0 


0 


18-DEC-87 
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9/22/94 Center Data File 



1 A 1 O 


41713-799-9115 


N 




C 


) c 


) ( 


) 11-AUG-88 




TYTI 
JAIL 


41214-688-3556 


KI 

N 




*• 

c 




) c 


% rtM A 1 1 /~\ mm 

) 23-AUG-88 




TVTY 
1 A 1 A 




1214-821-1910 


K 1 

N 


A 


i c 


) -15 


> 12 


I 7-APR-86 7-JUN-89 




TVTV 

TXTY 




I 903-597-6445 


N 




c 


I C 


> C 


) 29-APR-8822-NOV-91 




TVI IT 
1 XU I 




\ - - 


N 


2 


c 


) c 


> C 


) 7-APR-86 




TV\/I 1 
1 AVU 




i 512-732-9612 


N 


A 


c 


I c 


> C 


I 7-APR-86 




TV\A/ A 
1 XWA 


■ 4 


^ 512-732-9612 


N 


A 


c 


c 


I c 


I 7-APR-86 




1 aWH 


r— < 


i 512-732-9612 


N 


1 A 

A 


0 


c 


G 


x 7-APR-86 




1 IMHC 

UNUo 


99:800-292-9537 


N 


4 


0 


0 


0 


1 3-OCT-871 4-APR-92 




1 IT A U 

U 1 An 


51800-833-6667 


N 


4 


0 


0 


0 


7-APR-86 5-JAN-87 




i iti n 
U 1 LU 


5j 800-833-6667 


N 


4 


2 


1 


0 


7-APR-8631 -MAY-88 




1 iti o 
U 1 Lo 


5:801-321-1234 


N 


4 


0 


0 


0 


7-APR-86 




i ita nr* 
U 1 MO 


5j 800-833-6667 


N 


4 


0 


0 


0 


7-APR-86 3-MAR-88 




1 IT/~\Q 

U 1 Ur 


5 


800-833-6667 


N 




0 


0 


0 


18-NOV-87 8-AUG-88 




1 ITDP 
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OIS Universal Donor Programs 

The OIS Universal Donor programs need to be modified to: 

• Accept data from the Mainframe Gateway Server program. 

• Break up Match Run results by organ. 

• Write the Match Run results with the proper OIS header record for each 
organ to a file in a network shared directory. 
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ntestine donors 


Hepatitis Positive ,h 


*CV+ 


!+,- Liver, Pancreas, Kidney/Pancreas, Kidney, 
1 j Intestines, Pancreas/Intestines 


bpace filler |FILR 


6l 



Page 1 



Appendix 
Match Run Input Variances 



) 



NCNC - Carolina Organ Procurement Agency 

it 

Center = NCNC 

Then 

prompt user to enter actual donor center code 

set 1st 4 char of DLOCAL = actual donor center code 

Endlf 

NJTO - New Jersey Tissue & Organ Share 

if 

Center = NJTO 

Then 

prompt user to enter assigned transplant center code 

set 1st 4 char of DLOCAL = assigned transplant center code 

Endlf 

TXGC - Gulf Coast Organ Procurement Agency 

if 

Center = TXGC 

Then 

prompt user to enter region letter 

A Houston 

B Ft Worth 

C Lubbock 
set 1st char of DLOCAL = region letter 

Endlf 

MWOB - Midwest Organ Bank 

if 

Center = MWOB and Kidney Match is requested and Blood Group 
= A, A1 or A2 

Then 

prompt user to enter A donor ABO subgroup 
set 1st char of DLOCAL = ABO subgroup 

Endlf 

TXSA - South Texas Organ Bank 

if 

Center = TXGC 



Then 

prompt user to enter region letter 

A San Antonio 

B Austin 

C OPO Wide 
set 1st char of DLOCAL = region letter 

Endlf 

LAOP - Louisiana Organ Procurement Agency 

if 

Center = LAOP and Kidney Match is requested 

Then 

prompt user to specify if import donor 

set 1 st char of DLOCAL = import donor answer (Y or N) 

Endlf 

OKxx - All Oklahoma Centers 

if 

Center = OKxx 

Then 

prompt user to enter region letter 

A Oklahoma City 

B Tulsa 
set 1st char of DLOCAL = region letter 

Endlf 

TXSB - Southwest Organ Bank 
If 

Center = TXSB 

Then 

prompt user to enter region letter 

A Dallas 

B El Paso 

C Galveston 

D Tyler 
set 1st char of DLOCAL = region letter 

Endlf 

IAOP - Iowa Statewide OPO 

if 

Center = IAOP 



2 



# It is not clear how DLOCAL gets set here 

NEOB - New England Organ Bank 

if 

Center = NEOB and Kidney Match is requested 

# It is not clear how DLOCAL gets set here 

VAxx - Virginia Centers 

if 

Center = VATB 

Then 



Else 

Endlf 
If 

Then 
Elself 
Then 



prompt user to enter actual donor center code 

set char 2-5 of DLOCAL = actual donor center code 

actual donor center code = center code (i.e. VAxx) 



actual donor center code = VAMC or VAMV or VAHD 

set 1st char of DLOCAL = 1 

actual donor center code = VANG or VAKD 

set 1 st char of DLOCAL = 2 



Endlf 

set char 2-5 of DLOCAL = actual donor center code 

OC - Organ Center 

if 

Center = OCxx 

Then 

prompt user to enter actual Canadian donor center 

* validate actual Canadian donor center 

set 1st 4 char of DLOCAL = actual Canadian donor center 

Endlf 

* It is not clear what list or table is being used to validate the Canadian donor 
center. 
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Appendix 

Center Data and Center Name 
File Conflicts 



) 



9/22/94 



Center Code Conflicts 



v*enier uooe 


! Exists Only In . . . 


AHBM 


ICENTNAMES.DAT 


ADI !/*> 

AHUC 


iCENTERS.DAT 


AZHI 


iCENTNAMES.DAT 


AZPH 


iCENTERS.DAT 


CAG 


iCENTNAMES.DAT 


CASR 


CENTNAMES.DAT 


l~\l A 

DIAG 


CENTERS.DAT i 


FLTV 


CENTERS.DAT 


GAEX 


1 CENTERS.DAT 


INVI 


ICENTERS.DAT 


KSWV 


CENTNAMES.DAT 


KYKY 


ICENTERS.DAT 


MDSG 


CENTNAMES.DAT 


METR 


^CENTERS.DAT 


Ik At A A 

MIAA 


; CENTERS.DAT 


MNMG 


iCENTERS.DAT 


MOKV 


ICENTNAMES.DAT 


MONH 


iCENTNAMES.DAT 


MORE 


ICENTERS.DAT 


ft Jl/"^TO 

MOTS 


ICENTERS.DAT 


ft 4 VA/1A/I 

MWWL 


ICENTERS.DAT 


1 1 fO ft. 1 

NJSN 


ICENTERS.DAT 


OC01 


iCENTERS.DAT 


OC02 


ICENTERS.DAT 


OC03 


CENTERS.DAT 


OC04 


CENTERS.DAT 


OC05 


CENTERS.DAT 


OC06 


CENTERS.DAT 


OC07 


CENTERS.DAT 


OC08 


CENTERS.DAT 


OC09 


CENTERS.DAT 


OC10 


CENTERS.DAT 


OC1 1 


CENTERS.DAT 


UG12 


CENTERS.DAT 


UUlo 


CENTERS.DAT 


UU 1 4 


CENTERS.DAT 


UU 1 o 


CENTERS.DAT ] 


VJr\Mri 


CENTERS.DAT 




CENTNAMES.DAT 


3AI IP 


OfcN 1 LRS.DAT 


PDI IA 


ohNTERS.DAT 


oLJivirx \ 


^fclN I NAMco.DAT 


1 CovJ t 


^CMTCDP hat 

^tN 1 bRS.DAT 


TMI Q i 
1 INLD 1 


^ t NTN AM ES. DAT 


TNTN ( 


CENTERS.DAT 


TOFA ( 


CENTERS.DAT 


TXBA ( 


CENTNAMES.DAT 


UTLS ( 


CENTERS.DAT 


VARM ( 


CENTNAMES.DAT 


WIMC iCENTERS.DAT 


WIMM iCENTNAMES.DAT 
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Center Name File 



9/22/94 



Center Name File 



ALBP ! Baptist Medical Center i oj ( 


3 0|6 793KJ 


ALOB | Alabama Organ Bank i j 


j I 


ALU A ! Univ of Alabama Medical Center ! 61 ( 


J 0I6 793KJ 


ARBH ! Arkansas Baptist Medical Ctr. 3| k 


h_ 92I31092KJ 


ARBM ! Baptist Medical Center \ 21 21 


89'22189JA 


ARCH i Arkansas Children's Hospital 


0| C 


) ( 


) 31092KJ 


AROR i Arkansas Organ Proc Agency 


3 2 


! 8< 


) 3 289JA 


ARUA i(J of Arkansas Medical Center 


0 c 


» ( 


) 31092KJ 


A2GC iGENETRIX 


3 14 


T~ 9C 


)'31490JA 


AZGS iGood Samaritan Regional Med. 


0 c 


•r c 


I 6 793KJ 


AZHH jHealthwest Regional Med Cntr 


9 7 


88 


I 6 793KJ 


AZHI 'Arizona Heart Institute 


7! 7 


88 


7 788JA 


AZOB lArizona Organ & Tissue Bank 1 


0 3 


88 


52793KJ 


AZSJ !St Joseph's Hospital, Phoenix 


7 7 


88 


I7 788JA 


AZTV jVAMed.Ctr., Tuscon 


0| 0 


I 0i41288OO 


AZUA . University Medical Center 


0 0 


0 


6 793KJ 


CABE :St. Bernardine Medical Center 


5 


27 


93 


52793KJ 


CABH jAlta Bates-Herrick.East Bay CA 


2 


8 


88 


2 888JA 


CACL [Children's Hosp., Los Angeles 


i 5 


27 


93 


52793KJ 


CACS ! Cedars Sinai Medical Center 


5 


12 


89 


51289JA 


CADN j California Tx Donor Network 


5 


27 


93 


52793KJ 


CAEM j Eisenhower Memorial Hospital 


5 


27 


93 


52793KJ 


CAG | Golden State OPA 


1 


2 


91 


52793KJ 


CAGH 'Green Hospital of Scripps Inst 


7 


13 


90 


71390JA 


CAGS (Golden State Transplant Servic 


5 


27 


93 


52793KJ 


CAIM iU.C.L Medical Center 


5 


27 


93 


52793KJ 


CALA ; UCLA Medical Center, Harbor 


6 


7 


93 


6 793KJ 


CALB j St. Mary Medical Center 


6 


| 7 


93 


6 793KJ 


CALL ILoma Linda University Medical 


0 


0 


0 


52793KJ 


CAMH -Santa Rosa Memorial Hospital 










CAOP | Southern California OPPC 


1 


20 


88 


12088JA 


CAOT |San Diego Organ and Tissue 


7 


7 


89 


7 789JA 


CAPM | Pacific Medical Center 


0 


0 


0 


52793KJ 


CARZ |Hoag Memorial.Newport Bch, CA 


1 


25 


90 


12590JS 


CASB !San Bernardino County Medical 


5 


27 


93 


52793KJ 


CASC ; Univ of Southern CA Medical 


5 


27 


93 


52793KJ 


CASD 


Univ of CA, San Diego, Med Ctr 


0 


0 


0 


52793KJ 


CASF 


Univ of CA, San Francisco 


0 


0 


0 


52793KJ 


CASG 


Sutter Memorial Hospital 


6 


7 


93 


6 793KJ 


CASH 


Sharpe Memorial Hosp. 










CASJ 


Saint Joseph Hospital 


6 


7 


93 


6 793KJ 


CASM 


U. of California, Davis 










CASR 


Santa Rosa Memorial Hospital 1 


0 


14 


87 


101487JA 


CASU 


Stanford University 


2 


19 


88 


21988JA 


CASV 


St. Vincent Medical Center 


0 


0 


0 


6 793KJ 


CAUC | UCLA Medical Center 


6 


7 


93 


6 793KJ 


CAUH | USC University Hospital 


6 


7 


93 


5 793KJ 


CAWM | Western Medical Center 


6 


7 


93 I 


5 793KJ | 


CNHF ! Victoria Gen. Hosp.Nova Scotia 










CNUA : U. of Alberta, Edmonton 










CNVG ; Vancouver General Hosp. j 










CNWM Health Science Ctr.,Manatoba 




i ! 
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9/22/94 



Center Name File 



COCH 


IChildren's Hospital of Colo 


A 


\ 21 


) 90j42590JA 


COIA 


Immunological Assoc. of Denver 






|121290pw 


COMH 


Memorial Hospital 


c 


; L 27 


93I52793KJ 


COPM 


•Porter Memorial Hospital 


c 


I c 


I 0j52793KJ 


CORS 


! Colorado Organ Recovery System 


3 


2S 


I 88I52793KJ 


COSL ! Saint Lukes Hospital 


c 


c 


I 0|52793KJ 


COUC ! University Hospital 


0 


0 


0!52793KJ 


CTHH : Hartford Hospital 


0 


0 


C 


I 52793KJ 


CTYN ;Yale Univ., New Haven Hosp. 










DCCH 


Children's Hospital, National 


0 


0 


C 


6 793KJ 


DCGU 


Georgetown Univ. Med. Ctr. 










DCGW 


iGeorge Washington U. Med. Ctr. 










DCHU 


jHoward University Hospital 


0 


0 


0 


52793KJ 


DCTC 


i Washington Regional Tx Consort 


2 


10 


88 


52793KJ 


DCWH 


iWashington Hospital Center 


0 


0 


0 


6 793KJ 


DCWR 


i Walter Reed Army Med. Ctr. 










DEAI 


'Alfred 1. Dupont Institute 


5 


27 


93 


52793KJ 


FLAC 


•All Children's Hospital 


5 


27 


93 52793KJ 


FLBG 


Broward General Hosp. 










FLDB ! Halifax Hosp. 










FLFH j Florida Hosp. f Orlando 










FLFL j Gainsville/Jax Joint List 


8 


25 


<JC7 




FLFM j Florida Hosp. 










FLFR ! Southwest FL Regional Medical 


8 


29 


90 


52793KJ 


FLJM 


Jackson Memorial Hospital 


0 


0 


o 


6 793KJ 


FLJT 


Methodist Medical Center 


3 


29 


89 


52793KJ 


FLMP 


University of Miami OPO 


5 


27 


93 


52793KJ 


FLMV 


Miami VA Med. Ctr. 










FLOM 


Orange Memorial Hosp. 










FLSF 


U. of South Florida 










FLSW 


Lifelink of Southwest Florida 


5 


27 


93 


52793KJ 


FLTG 


Tampa General Hosp. 










FLTO 


Tallahassee Mem. Reg. Med. Ctr 










FLUF 


U of FL Medical Center, Shands 


0 


0 


0 


52793KJ 1 


GAEH 


Egelston Children's Hospital 


0 


0 


0 


52793KJ 


GAEM ! 


Emory University Hospital 


0 


0 


0 


52793KJ 


GAEU ! 


Emory Univ. Hosp. 










GAGM 


Grady Memorial 










GALL 


Life Link of Georgia 


2 


10 


88 


52793KJ 


GAMC 


Med. College of Georgia 










GAPH 


Piedmont Hospital 


6 


7 


93 


6 793KJ 


GASJ 


St Joseph's of Atlanta 










GAUH 


University Hospital [ 


6 


7 


93 


6 793KJ 


HIOP 


Organ Donor Center of Hawaii 


5 


27 


93 


52793KJ 


HISF 


St. Francis Medical Center 


0 


0 


0 


6 793KJ 


HOPE 


HOPE Foothills Hosp. 1 










IAIM 


owa Methodist Medical Center 1 


1 


24 


87 


52793KJ 


IAIV 


owa City V A Med. Ctr. 










IAMH <Mercy Hospital Medical Center 


0 


0 


0 


52793KJ 


IAOP ! Iowa Statewide OPO 


9 


25 


89 


52793KJ 


ILCM ! Children's Memorial Hosd. 










ILCR i Chicago Reg. Org. & Tissue Bnk 


0 


0 


0 


52793KJ 
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9/22/94 



Center Name File 



ILED jEdgewaterHosp. 










ILEH 


Evanston Hospital ' 1 


■ 


2 11 


3 8 


7 52793KJ - 


ILEN 


Evanston Hosp. 


i 








(LIP 


Regionl Organ Bank of Illinois 1 


i 


2 2" 


I 8- 


f 52793KJ 


ILLU 


Loyola University 


( 


) ( 


) ( 


) 6 793KJ 


ILLV 


Lakeside V A Med. Ctr. 










ILMM 


Memorial Medical Center 


( 


) C 


) ( 


) 6 793KJ 


ILMN 


t 










ILNM j Northwestern Memorial Hosp. 










ILPL i Rush Presb. St. Luke's Med. Ct 










ILSF ! St. Francis Medical Center 


1 c 


1 C 


C 


I 6 793KJ 


ILSM jSt. Margaret Hosp. 










ILUC (University of Chicaqo Med. Ct 










ILUI ;U. of Illinois Med. Ctr. 










ILVA iHinesVA 


8 


31 


89 


52793KJ 


INCI (Central Indiana Regional Blood 


5 


27 


93 


52793KJ 


INDV ILakeview Hospital, Danville 


4 


12 


88 


52793KJ 


INEV St Mary's Hospital, Evanston 


0 


0 


0 


52793KJ 


INFW ] Lutheran Hospital, Fort Wayne 


0 


0 


0 


52793KJ 


INHA 


St Margaret's Hammond 


0 


0 


0 


52793KJ 


INIM 


Methodist Hospital of Indiana 


0 


0 


0 


52793KJ 


INIU 


Indiana Univ. Med. Ctr. 










INIV 


Indianapolis V A Hosp. 










INLA 


St Elizabeth's Lafayette 


0 


0 


0 


52793KJ 


INLF 


'Lutheran Hospital 


0 


0 


0 


6 793KJ 


INLH 


Lutheran Hospital of Ft. Wayne 


0 


0 


0 


52793KJ 


INMU 


Ball Memorial Muncie 


0 


0 


0 


52793KJ 


INOP 


Indiana Organ Procurement Org 1 


2 


23 


87 


52793KJ 


INSB 


St. Joseph Hospital 


0 


0 


0 


6 793KJ 


INSV 


St. Vincent Hospital & Health 


0 


0 


0 


6 793KJ 


INTE 


Tri-State Renal Disease Ctr. 










INVA 


VA Hospital Indianapolis 


0 


0 


0 


52793KJ 


KSFT 


St. Francis Hosp., Topeka 










KSFW ! 


St. Francis Hosp., Witchita 










KSUK 


Univ of Kansas Medical Center 


0 


0 


0 


6 793KJ 


KSWV 


VA Med. Ctr., Witchita 










KYHH 


Humana Hospital, Audobon 


5 


27 


93 


52793KJ 


KYJH 


Jewish Hosp. 










KYKC 


Kosair Children's Hospital 


6 


7 


93 


6 793KJ 


KYUK 


U. of Kentucky Med. Ctr. 










KYUL 


U. of Louisville OPA 










KYWK 


OPA of Western Kentucky 










LANO 


Louisiana State Med. Ctr. 










LAOF 


Ochsner Foundation Hospital 


0 


0 


0 ! 


52793KJ 


LAOP I 


Louisiana Organ Procrmnt Agncy 


3 


17 


88 ! 


52793KJ 


LASB 


Southern Baptist Hopital 










LASM ! 


Schumpert Medical Center 


0 


0 


0 ! 


32793KJ 


LASU | 


-ouisiana State Univ, Med. Ctr 










LATU 


rulane Univeristy Med. Ctr. 










LAWK \ 


Mllis-Knighton Medical Center 


5 


27 


93 I 


52793KJ 


MABI j Beth Israel Hospital 


91 


0 


0 I 


52793KJ 


MABS IBaystate Medical Center 


51 


27 


93 J 


52793KJ 
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9/22/94 Center Name File 



MABU j Boston University Medical Cntr 


C 


j c 


I 0;6 793KJ 


MAB V j Boston V A Medical Center 


C 


• c 


I 0J6 793KJ 


MACH : Children's Hospital Med. Cntr 


c 


0 


0j6 793KJ 


MAHS i Harvard Unit-NE Deaconess Hosp 


I 
I 




MALC iLahey Clinic Medical Center 


o 


n 


■ fi 




MAMG -Massachusetts General Hospital 


o 


rj 


C 


6 7Q1K J 


MANM ;New England Medical Center 


o 


n 

\j 


f] 




MAPB ;Brigham & Women's Hospital 


o 


n 

V 


n 




MAUM jUniv of Massachusetts Med Schl 


o 


0 


n 
u 




MDBC | Francis Scott Key Medical Cntr 




A 
\J 


0 


6 793KJ 


MDJH 'Johns Hopkins Hospital 


o 


A 
\J 


0 


6 793KJ 


MDPC iMarylandOPO 1 


1 

1 


19 


90 


52793KJ 


MDSG ! Shady Grove Adventist Hospital 


c 


Ol 
t / 


93 


52793KJ 


MDUM i Univ of Maryland Hospital 


n 


U 


0 


6 793KJ 


MEMC Maine Medical Center 


n 


u 


0 


52793KJ 


MIBH William Beaumont Hospital 


n 

V 


A 

u 


0 


'52793KJ 


MICH : Children's Hospital of Michign 


n 


u 


0 


,52793KJ 


MIHF : : Henry Ford Hospital 


n 


u 


0 


52793KJ 


MIHH i Harper Hospital 




ell 


93 


52793KJ 


MIHM -Hurley Medical Center 


n 


A 

u 


0|52793KJ 


MIKZ iBorgess Medical Center 


0 


A 

yj 


0I52793KJ 


MIMC ; Grace Hospital 


o 


A 

\j 


0'6 793KJ 


MIMS | 






1 

i 


MIOP Organ Procurmnt Agency of Ml 


5 


27 


93 


52793KJ 


MISH ! Mich. State U. Sparrow Hosp. 

■ ■■ i L- *_ „ 










MIS J ; St John's Hospital and Medical 


7 


o 


90 


52793KJ 


MISM iMich. State U. St. Mary's Hosp 










MITS i Michigan TX Society 

, S 1 










MIUM illniv. of Michigan Medical Cntr 


0 


o 


0 


6 793KJ 


MIVA ;Ann Arbor V A Med. Ctr. 










MIWS 'Wayne State Univ. Hutzel Hosp. 










MNAN | Abbott North Western 










MNHC | Hennepin County General Hosp. 










MNMC i Mayo Clinic 










MNMV 


Minneapolis V A Medical Center 


0 


0 


0 


6 793KJ 


MNOP 


luPPER MIDWEST OPO 


6 


2 


88 


6 288JA 


MNSM 


St Mary's Hospital 


5 


27 


93 


52793KJ 


MNTL 


Univ Minn Tissue Typing Lab 1 


2 


29 


88 


6 793KJ 


MNUM 


Univ of Minnesota Medical Cntr 


0 


0 


0 


6 793KJ 


MOBH 


Barnes Hospital 


0 


0 


0 


6 793KJ 


MOCG 


Cardinal Glennon Children's Hs 


5 


27 


93 


52793KJ 


MOCH 


St Louis Children's Hospital 


0 


0 


0 


52793KJ 


MOCM 


The Children's Mercy Hospital 


0 


0 


0 


52793KJ 


MODU 


De Paul Health Center 1 


2 


10 


87 


121087 JA 


MOJH 


Jewish Hosp. 










MOKV 


Kansas City V A Hosp. 










MOLH 


St. Luke's Hospital of Kansas 


0 


0 


0 


6 793KJ 


MOMA j 


Mid-America Transplant Assoctn 


3 


24 


88 


52793KJ 


MOMM ! 


Menorah Medical Center 


1 


6 


88 


1 688JA 


MONH ; Northland Comm. Dialysis Ctr. j 








MORH j Research Medical Center I 


0 


0 


0 


6 793KJ 


MOSL ! St. Louis Univ. Medical Center 


0 


0 


0!6 793KJ 
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Center Name File 



MOUM 


iU of Missouri Med Ctr 


i 








MSUM 


U of Mississinni Med. Ctr 










MWOB 


Midwest Organ Bank 










NCBG 


Bowman Gray School of Medicine 










NCBH 


North Carolina Baptist Hosp. 










NCCM 


i Charlotte Memorial Hospital 


u 


n 
u 


a 
U 


o /yoi\J 


NCCP 


'Carolina OP A 










NCDU 


IDuke University Medical Center 




n 

KJ 


a 
u 


A 7C3V 1 

o /yor\J 


NCDV : Durham V A Medical Center 


a 
U 


u 


A 

u 


D /yoKJ 


NCEC j East Carolina University 


n 
u 


n 

u 


n 
u 


R 1 

o /yofvj 


NCMH i North Carolina Memorial Hosp. 










NCNC i Carolina Organ Procurement Agy 


6 

w 




oo 




NCRC ; Charlotte Red Cross 






fift 


OOCOO 1 A 
OlOOOJM 


NDDH ; Dakota Hospital North Dakota 


w 


a 

o 


ftp 


41 7QH l^ 


NDMC ; Medcenter One Hospital 1 


o 


14 


Aft 


o /yor\j 


NDSL jNorth Dakota St Luke s 


A 
•t 


1 / 


on 
yu 


^i7on ic 
*fi /yujo 


NDTB ! N. Dakota Tx Svc Bismark Clini 


1 
I 


1 Q 

iy 


on 
yu 


1 1QOA IC 

i lyyujo 


NDTC |n. Dakota Tx Svc Bismark Hosp 


1 


iy 


yu 


i 1 AAA IC 


NDTS ITranspInt Services of Fargo 1 


A 
U 


IO 




1 AH QOQ I A 

lUiooyJA 


NEBM -Bryan Memorial Hospital 


O 


/ 


93 


6 793KJ 


NECM j Bishop Clarkson Memorial Hospl 


' a. 


f 


93 


6 793kj 


NEOB i New England Organ Bank 










NEOR j Nebraska Organ Retreival Sys. 










NEOX jNew England Organ Bank OTO 


n 


u 


0 


41288CC 


NESJ ! Saint Joseph Hospital 


a 
u 


7 


93 


6 793kj 


NEUN j University of Nebraska Medical 


fx 


7 


93l6 793kj 


NHDH jMary Hitchock Memorial Hosp. 


O 


7 


93 


6 793kj 


NJBI I Beth Israel Medical Center 


o 


n 


0 


6 793kj 


NJLL jOur Lady of Lourdes Med. Ctr. 


o 




0 


6 793kj 


NJSB |St. Barnabas Medical Center 




n 

u 


0 


6 793kj 


NJTL 


New Jersey Histo Lab 1 






88 


121288JA 


NJTO 


New Jersey Tissu & Organ Share 


4 


10 


90 


41090JA 


NJUH 


University Hospital 


O 

c 


I o 


89 


21389JA 


NMAQ 


U. of New Mexico 










NMOP 


New Mexico Donor Program 




7 


93 


6 793kj 


NMPH 


Presbyterian Hospital 


o 


n 


0 


6 793kj 


NORS 


Nebraska Organ Retrieval Svs 


4 


12 


88 


41288JS 


NVHH 


Humana Hospital Las Vegas 


7 


3 


90 


7 390JA j 


NVLV 


Nevada Donor Refer System 


4 


11 
■ i 


88 


41188JA 


NVUM 


So Nevada Medical Center 


2 


28 


90 


22890JS 


NYAM 


Albany Medical Center 


o 


o 


0 


6 793kj 


NYAP 


Albany Organ Proc Agency 1 


2 


12 


89 


121289JA 


NYBC 


Children's Hospital of Buffalo 


6 


7 


93 


6 793kj 


NYBU 


Buffalo Gen. Hosp. OPA of W.NY 










NYCL 


Columbia Presb Tissue Typ. Labi 


2 


20 


89 


1 22089 JA 


NYCO 


NY Center for Liver Txplant 


7 


20 


90 


72090JA 


NYCP 


Columbia Presbyterian Hospital 


0 


0 


0 


6 793kj 


NYDP 


New York Gift of Life 1 


1 


13 


87 


11 1387 JA 


NYDS 


Downstate Medical Center 


0 


0 


0 


6 793kj 


N YEC | Erie Countv Medical Center 


6 


7 


93 


6 793kj 


NYFL i Strong Memorial Hospital 


6 


7 


93 


6 793kj 


NYIL iRogosin Tissue Lab 1 ' 


0 


26 


89 


1 02689 JA 
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9/22/94 



Center Name File 



NYMA jMontefiore Hospital Med. Cntr i ( 


) ( 


)|_ 0j6 793kj 
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OHLC ;Life Connection of Ohio 


3 
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OHLI jLima Dialysis Center 


0 
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OHLM jLima Memorial Hospital 


0 


0 
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OHLP : Lifeline of Ohio 1 


u 


20 


87 
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U 


0 


0 
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OHMG ! Metro General Hosp. 










OHMI 
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n 
U 


0 


0 
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u 


0 


0 
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u 


0 
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i 


16 


89 
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Ohio State University Hospital 


n 

u 


0 


0 
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Portsmouth Dialysis 


o 


0 


0 
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Riverside Hospital Columbus 


o 


0 


0 
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St Elizabeth's Medical Center 


9 


27 
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Springfield Dialysis 


0 


0 


0 
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St. Vincent's Hosp. & Med. Ctr 
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7 


93 
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Univ of Cincinnati Med. Cntr. 


0 


0 
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5 


4 


88 . 


5 488JA 
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Zanesville Dialysis Center 


0 
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OKMD 'Oklahoma Memorial Hospital 



OKOP 



OKOV 



OKSA 



OKTH 



PAAE 



PAAG 



PAGM 
PAHE 



Oklahoma Organ Sharing Network 



Oklahoma City VA Medical Centr 



St. Anthony's Hospital 



OKSF ISt. Francis Hospital 



ORUO I U. of Oregon Health Sci. Ctr. 



13 



; Albert Einstein Medical Center 
Allegheny General Pittsburgh 1 



PACH | Children's Hosp. of Pittsburgh 
IPACP Children's of Philadelphia 
PADV 



Delaware Valley Transplant 



Geisinger Medical Center 



jHershey Medical Center 



26 



28 



18 



89 



93 



6 793kj 



3 389JA 



6 793kj 



6 793kj 



KJ 
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PAHM | Hahnemann Medical College 
1PALV j Lehigh Valley Hospital 



93 
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PAPT 



' University of Pittsburgh 
I St Chistopher's Hosp./Children 



PASC 



PATF j Pittsburg Transplant Foundatn 1 



23 



87 



1 02387 J A 



PATJ i Thomas Jefferson Univ. Hosp 



PATU 
PAUP 



Temple Univ. Hosp. 



U. of Pennsylvania Hosp. 



PRSJ 



Auxilio Mutto Hospital 



0|6 793kj 



PRVA 



ROPA 



SCDF 



SCKC 



SCMU 



Puerto Rico VA 



R OPA of Southern California 



Doheny Foundation (SPEC CORNA) 



Kellogg Clinic (SPEC CORNEA) 
Med. College of South Carolina 



SCOP j South Carolina Organ Procurmntl 



SCWC j Wisconsin (SPEC CORNEA) 
SDMK !McKennan Hospital 



21 



41288JS 



41288JS 



41288JS 



87 102187JA 



93 



41288JS 



6 793kj 



SEOP i Southeastern Organ Procurement 



TNBM 
TNDC 



| Baptist Memorial, Memphis 



88 



3 388JA 



Tennessee Donor Svcs Nashville 



41288JS 



TNDS 



Tennessee Donor Services 



88 



6 288JA 



TNEM 



TNET 



TNJC 



TNLB 



TNMH 



TNMS 



TNNV 



TNPV 
TNST 
TNUK 



ITNUT 



Erlanger Medical Center Tenn. 1 



East Tennessee ROPA 



19 



Johnson City Medical Center 



Le Bonheur Children's Center 



Methodist Hospital of Memphis 



Midsouth Transplant Foundation 



Nashville V A Med. Ctr. 



Nashville Presbyterian 



St. Thomas Hospital 



23 



U. of Tenn. Med. Ctr., Knox. 



U. of Tenn. Med. Ctr., Nash. 



89 



101989JA 



88 



9 888JA 



93 6 793kj 



94 



93 



91 



89 



2 794KJ 



6 793kj 



1 391JA 



62389JA 



TNVU 



ITXAD 
PTXAV" 



Vanderbilt Univ. Med. Ctr. 



Breckinridge Hosp. 



TXBA 



TXBC 



Audie Murphy VA Medical Center 



(Brooke Army Medical Center 
!U. of Texas Health Science Ctr 



|TXBU i Baylor University Hospital 1 



J3 
0 



29 



93 



88 



6 793kj 



kj 



6 793kj 
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G 


1 c 


0 
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TXHH | Herman Hospital 










TXHI iTexas Heart Institute 










TXHS ! Humana Hospital, San Antonio 


1 


25 


90 


12590JS 


TXHT jHome Training, Statewide 










TXJL 


jGalveston Tissue Antigen Lab 


8 


30 


89 


83089JA 


TXJS 


John Sealy HospVUniv of Tex. 










TXKD 


South Texas Kidney Disease Ctr 










TXLA 


Laredo 










TXLG 


Lubbock General, Texas 


4 


14 


88 


41488JA 


TXLM , 


Methodist Hospital, Lubbock 


7 


2 


90 


1 7 290 J A 


TXMC 


1 Methodist Central, Dallas 


0 


0 


0 


'41288 JS 


TXMH 


Methodist Hospital 


0 


0 


0 


1 6 793kj 


TXPM i Parkland Memorial Hospital 


0 


0 


0 


6 793kj 


TXSA ; South Texas Organ Bank 










TXSB ; Southwest Organ Bank 


9 


8 


88 


9 888JA 


TXSH 


Spohn Hospital 


0 


0 


0 


6 793kj 


TXSM 


Sierra Medical, EI Paso 


3 


29 


88 


32988JA 


TXSP 


St. Paul Medical Center 


0 


0 


0 


6 793kj 


TXSR 


Santa Roas Hosp. 










TXST 


South Texas Dialysis Center 


0 


0 


0 


6 793kj 


TXSW 


University Texas at Dallas 1 


z 


18 


87 
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TXTC jTexas Children's Hospital 


O 


7 


93 


6 793kj 


TXTL j Univ Texas SW Medical Center 
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O 


23 


88 
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TXTX 1 Baylor University Hospital 


U 


0 


0 
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TXTY 


Medical Center Hosp, Tyler 


A 

4 


29 


88 
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Vail Urology Clinic 










TXWA 
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TXWH 


Wilford Hall Med. Ctr. (USAF) 
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United Network for Organ Shari 










UTAH 


UTMC&UTLD Cardiac TX Proqram 










UTLD 


Latter Day Saints Hospital 


u 


U 


0 


6 793kj 


UTMC 


Intermount Org. Bank/U. of UT 










UTOP 


Intermountain Organ Recovery 1 


1 




87 


111887JA 
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Primary Children's Medical Ctr 




7 


93 


6 793kj 
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VA Medical Center, Salt Lake 


6 


7 


93 


6 793kj 
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Fairfax Hospital 


0 

\j 




A i 
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VAFP 


Fairfax Hospital Association 1 


0 




87 
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Henrico Doctors' 
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89 I 


81089ja 
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Children's Hosp Kings Dauahter 
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89 < 
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Leigh Memorial Hosp. 










VAMC i Med. College of Virginia 










VAMV ! McQuire V A Medical Center 
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14 


89 


31489JA 
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Froedtert Memorial Luth. Hosp. 
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St. Luke's Hosp. & Org.Network 










WIUW 


Univ of Wisconsin Hospital 


0 


0 


0 
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Charleston Area Medical Center 
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14 
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31488JA 
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0 


27 
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ABSTRACT 



CHARLES J. HUTSON. XPEDITE organ information system 

Purpose. To research, analyze and present the rational for the 
development of the Xpedite organ information system by the 
United Network for Organ Sharing (UNOS). Further, to explain the 
components and processes of the Xpedite system. 

Method. The author interviewed Mr. David Klein, M.E.A., UNOS 
Director of Computer Services, and used personal insight of the 
system, gained through the author's development of a marketing 
plan for Xpedite during October and November, 1994. 
Additionally, the author is a member of the UNOS Patient Affairs 
Committee and has been an advocate for transplant patients since 
1992. 

Report Contents. This report includes the following; (I trans- 
plantation: A Brief History, (2) Current System, (3) Purpose 
Statement, (4) Scope of the Project, (5) The Xpedite System, (6) 
Xpedite Context Diagram, (7) Xpedite Figure 0 Data Flow 
Diagram, (8) Implications for Organ placement, (9)Xpedite 
Benefits Summary, (10) Considerations for Future Development, 
(1 1 ) Input/Output Documents with Descriptions, (12) PTE.C.E.S. 
Problem-Solving Framework, and (13) Appendices with Skytel 
Network Information, UNOS GST Framework and Input/Output 
Forms 



Copyright 1995 



Microsoft Windows is a trademark of Microsoft Corporation 
Lotus Notes is a trademark of Lulus Development Corporation 
Skytel is a irailcmark of Mobile Telecommunications Technologies 



PREFACE 



During the past two years the United Network for Organ Sharing 
(UNOS) has been working on a system to reduce the time interval 
between initial notification of a potential donor by a hospital, and 
the final placement of the organ for transplantation. The evolution 
of this system has resulted in the evaluation of several promising 
possibilities, only later to have these ideas fall victim to better 
alternatives. This has also been true of the process of naming this 
system. In the early development there was no name, then as the 
system gained shape it was named VITALINK. However, as the 
system approached the phase where marketing could begin, a 
trademark search was conducted and it was discovered the name 
was protected. A search for a new name ensued and in the interim 
the system was called the Organ Information System. Finally, an 
official and public name for the system was selected-- XPEDITE. 
This paper attempts to present the rationale used for determining 
the need for Xpedite, and to discuss the components and benefits 
of the system. 
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TRANSPLANTATION: A BRIEF HISTORY 

In the early 1950's Dr. David Hume of Harvard University ushered in the era of 
transplantation, with the successful transplantation of renal organs in the thighs of patients. For 
more than a decade several different procedures and immunosuppression medications were tried 
with very limited success. Then in 1963 a series of drug therapies were developed that resulted in 
reports of one year survival rates of up to 85% in renal patients. In 1967 Dr. Christian Barnard 
performed the first successful heart transplant. In the early 1970's Dr. Roy Calne in England and 
Dr. Tom Starzl in the U.S. successfully began liver transplantation. 1 In addition to improvements 
in surgical procedures the two most significant developments in transplantation during this 
period were (I) the development of the highly successful immunosuppression medication, 
cyclosporine and (2) the development of a reliable solution for the preservation of organs at the 
University of Wisconsin (UW solution). 

With all of these advances, the number of patients wanting transplants out-stripped the 
available donor supply. The federal government felt that the early methods of organ sharing 
should be formalized through legislation. In 1984, Congress passed the law creating the national 
Organ Procurement and Transplantation Network (OPTN). In 1986 the United Network for 
Organ Sharing (UNOS), a creation of the previous voluntary organ sharing system of the South 
East Organ Procurement Foundation (SEOPF), received a contract from the federal government 
to implement the OPTN system. 2 Since then, UNOS has continued to implement programs and 
systems to (I) successfully match available donor organs with the most suitable transplant 
candidate and (2) explore new and innovative ways to make the system more responsive to meet 

Michael G. Phillips, UNOS Organ Procurement. Prese rvation and Distribution in 
Transplantation (UNOS 1991) 
2 IBID.,pg.5 
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the needs of transplant candidates. Of major concern to UNOS, is the development of programs 
and systems that will close the gap between the number of organs needed and the number of 
organs available. This shortage alone results in the death of eight people each day. 

UNOS* most recent innovation to solve this discrepancy is the Xpedite organ information 
system. The major benefits of Xpedite are (1) Xpedite will reduce the amount of time necessary 
to place available organs and (2) implementation of Xpedite will result in an increase in the 
number of usable organs. With Xpedite, notification of transplant center priorities for all organs 
(of a single donor) are simultaneously are transmitted to all transplant centers; thus widening the 
scope of organ offerings and thereby resulting in the opportunity for greater organ placement. 

CURRENT SYSTEM 
In 1993, there were 33,352 transplant candidate waiting on the UNOS list (up from 
29,415 in 1992, a 13.4% increase).' Further, in 1993 there were 18,168 transplants performed at 
265 transplant centers. 4 These centers receive organs from 67 organ procurement organizations 
(OPO), with each of the approximately 4, 100 donors, donating up to seven major organ (heart, 
liver, pancreas, two lungs, and two kidneys). The focal point of the organ recovery process is the 

organ procurement coordinator, who must: 

1. Provide complete management of the donor including all medical related processes, 

2. Interface with the grieving donor family, 

3. Complete a series of as many as seventeen different forms (copies of these forms are 
included in Appendix C) concerning donor characteristics, laboratory information and organ 
specific data, 

4. Fax the forms to the UNOS organ center to be entered in the UNOS computer system 
so that a match run can be initiated, 

5. Wait for match run results and then review results to understand the priorities of each 
potential transplant candidate, 

6. Call each transplant center, one after the other, with a priority for EACH organ, and; 

Annual report of the US Scientific Registry of Transplant Rec ipients and the Organ 
Procurement and Tra n cp| antat j on Network (UNOS, 1994) 
IBID., P g.ES-15 
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7. Explain verbally to transplant center officials, the donor information with sufficient 
specificity for the center to make a decision with regard to acceptance or rejection of the organ 
for their candidate. 

If an organ is rejected by a transplant center, this process is repeated again and again until each 
organ is accepted. Valuable time, often hours, are lost and frequently placing multiple organs is 
impossible because of time constraints. 

Some of the difficulties of this system are obvious, the most serious being the potential 
for miscommunication and time delays waiting for return calls between transplant centers and 
procurement coordinators. The stress on procurement coordinators results in increased risk of 
error in donor management. Other difficulties are less obvious such as misinformation being 
communicated to the transplant center resulting in acceptance of an organ and then later, once the 
surgeons arrive to remove the organ, a reassessment results in the receiving hospital declining the 
organ. This is an expensive and time consuming problem which often results in an otherwise 
usable organs not being placed due to deterioration of the organ. Another potential problem is 
that the coordinator recovers the organ and ships the it to the transplant center. The receiving 
transplant center rejects the organ because of the limited amount of information available at the 
time of acceptance, increasing expense and the potential for loosing a life saving organ. 

PURPOSE STATEMENT 
The purpose of this project is to research, analyze and present the rational for development of a 
system that will reduce the time necessary to place human organs for transplantation and to 
explain the components and processes necessary to accomplish the project objectives. 

SCOPE OF THE PROJECT 
Due to the enormous complexities of organ recovery and placement process, it is necessary in the 
context of this analysis to limit the discussion to an overview perspective of the system. Such a 
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sophisticated and revolutionary system does and will continue to require modifications to the 
system and procedures necessary for implementation. To this end, the system has been through 
Alpha and Beta testing at various Organ Procurement Organizations (OPO) in throughout the 
United States. Currently, final testing is underway at the UNOS Organ Center and some OPO's. 
Upon the successful completion of this testing, proper training materials will be prepared by 
UNOS. At that point marketing, installation, and full nationwide implementation will begin. 
However, for the purpose of this discussion the focus will be viewing the general principles and 
methods used in the deployment of this system. 

THE XPEDITE SYSTEM 
Xpedite is a system that combines the portability and capabilities of today's sophisticated 
notebook personal computers and Microsoft Windows compatible software to improve the 
process of decision making during the placement of human organs for transplantation. Each year 
more than 18 ? 000 people, with life threatening end stage organ disease, rely on the success of this 

process to save their lives. With Xpedite, the procurement coordinator: 

1 . Collects donor data on a notebook PC. All seventeen forms (which prior to Xpedite 
were completed by hand) necessary for the completion of the organ placement process have been 
programmed into the PC as input/output screens (a complete discussion of these input/outputs are 
included on page 1 1 ) using Lotus Notes software. 

2. Once sufficient data has been collected the coordinator, using the notebooks' modern, 
dials into the UNOS Organ Center and connects to the Xpedite server. The coordinator 
downloads the information and replicates the complete donor file onto the Xpedite server, 

3. The coordinator initiates a Match Run, 

4. Match Run results are simultaneously transmitted back to the coordinator and ALL 
transplant centers with priority are notified via a Skytel digital pager, 

5. Transplant center professionals with Xpedite software can then dial-in to the Xpedite 
server and view the donor case file and/or download the file to their system (centers without 
Xpedite can still receive the donor file using the Xpedite Fax-back feature), and; 

6. The coordinator calls the center for a decision on accepting or rejecting the organ. If 
the organ is accepted that is the end of the process, if rejected the coordinator continues to call 
centers, in order of priority, until the organ is accepted. 
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The Match Run is a key point in this process. The coordinator may chosen to initiate the match 
run to determine, for example, the first 25 centers for kidneys, first 1 5 for livers and so on for 
each organ. As the name implies, the information concerning the donor is matched with the list 
of more than 38,000 (1995 estimate) waiting transplant candidates to determine the prioritization 
of candidates to receive the donor organs. The criteria for this analysis and prioritization is very 
complex. Evaluation is based upon a balance of utility, justice and medical need. The needs of 
the local community are balanced against the belief that donor organs are a national resource. A 
point system has been implemented for ranking candidates for all solid organs except lungs. This 
point system includes evaluation based on severity of condition, degree of compatibility with the 
donor, distance between the donor and the candidate and length of time on the list. These and 
other evaluation criteria are included in the Match Run. 

Upon completion of the Match Run, results are transmitted to the OPO's procurement 
coordinator (results include the candidate identification number, type of organ and the name of 
the transplant center with their priority and other related information) who reviews the results 
and begins contacting transplant centers to discuss the case and elicit a decision from the center 
to accept or reject the offer. 

Xpedite broadcasts to each of these centers data on their priority. Each center's contact 
representative will be equipped with a Skytel digital pager (information concerning Skytel is 
included in Appendix A). Xpedite transmits a message that may include the donor's UNOS 
identification number, type of organ being offered, priority number and contact telephone 
number. 
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Armed with this information the transplant center surgeon or transplant coordinator can 
dial into the Xpedite system server at UNOS. If the transplant center has purchased the Xpedite 
system they can then use their system to review the donor data on-line or download the 
information to their system. In either case, this information is then evaluated by center officials 
and a decision can be made whether to accept or reject the organ, if it is offered, in advance. 

The advantages of this system are that center personnel are making decisions based upon 
access to the entire donor file (not just what can be communicated by phone and fax as were 
previously done) and that the center can make advance decisions. If an offer is made, the center 
can quickly give the procurement coordinator a fully informed decision. If the decision is to 
accept the offer and transplant the organ, the organ recovery and transplant process can begin 
immediately. On the other hand, if the decision is to reject the offer, the coordinator can be 
quickly informed and move on to another inquiry. 

Those centers who do not purchase the Xpedite system can still access the donor 
information by using the Xpedite fax-back system. With this component of the Xpedite system 
center personnel dial-in their request to the electronically answered system and the system 
immediately faxes the requested information back. 

Xpedite will reduce the organ placement process by several hours and will result in the 
placement of more usable organs. For some organs there is a very short window of opportunity 
for placement and transplantation (4-6 hours for hearts and lungs), while others have more time 
(24-48 hours for kidneys and livers). It is imperative that the data collection and organ placement 
processes operate efficiently. With Xpedite the timeliness of these processes are improved. 
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IMPLICATIONS FOR ORGAN PLACEMENT 

It is the author's belief that there are factors inherent in the existing system that often 
cause the more time sensitive organs to be placed last or not at all, in favor of organs with a 
longer time in which successful placement can result. The primary reasons for this are: 



( 1 ) experience on the part of procurement coordinators that tells them that placement is a 
long and tedious process, therefore it is more efficient to spend the time placing the 
organs you can (liver and kidneys) than to chase placement of organs with shorter life 
cycles (heart and lungs) that you may not get placed anyway; 

(2) that this system was developed and perfected over the years by people whose primary 
interest was renal disease and it's treatment and therefore there is a natural predisposition 
toward kidney organ placement and; 

(3) that there are five to six times as many kidney patients awaiting transplantation as 
there are hearts and lungs, therefore there is a perception that the need for kidneys is 
greater than for other organs. 

With Xpedite the hope is that improvement in this process will result in greater placement of all 
types of organs over a short period of time. 



XPEDITE BENEFITS SUMMARY 
The full implementation of the Xpedite system will result in many benefit to patients, 
procurement coordinators, transplant center professionals, UNOS staff and medical researchers 
in the field of transplantation. Following is a summary of these benefits: 

1 . Time Reduction - Xpedite compresses the process, enabling a candidate match for an 
organ in the least amount of time possible. The time saved, results in a direct increase in life 
saving organ placement. 

2. Donor Family - Families who consent to donate their loved one's organs must wail 
hours until organs are recovered. Xpedite speeds the placement process, sparing families a 
lengthy and anxious wait before the body can be released for funeral arrangements. 

3- Lower Medical Costs - Prior to organ recovery, donors are maintained in expensive 
critical care facilities during the placement process. Xpedite lessens the time donors spend in 
expensive facilities, thus reducing insurance and Medicare/Medicaid costs. 

4. Higher Productivity/! g§s Sirocc - Xpedite allows procurement coordinators to 
concentrate on donor management by automating much of the placement process. 



Page 9 



5. Medical Research - Xpedite will produce a rich research database that does not exist 
today. This database will be utilized to analyze and study the donor placement process, the donor 
population and may ultimately improve the national policies on organ allocation. 

CONSIDERATIONS FOR FUTURE DEVELOPMENT 

During the development of this report it became clear that the improvements Xpedite offers are 

many and varied. Further, as a result of the immediacy of this system, it would become possible 
for time sensitive data, such as an active donor case record, to become outdated very quickly. The 
impact of this prospect, is that during the decision making process the donor record at the 
transplant center does not contain an information base as current as the procurement coordinator's 
case file nor that on the Xpedite server. Therefore, it may be advisable upon wide spread 
implementation of the system to establish a procedure to instruct transplant centers to update 
their record at some pre-determined time interval as long as the case remains active. Possible 
long term solutions may be to include some method of time stamping all records with the date 
and time of last update. This would assure that all systems in the process have that most current 
data available. 

Additional considerations for development might include further automation of the decision 
making process by eliminating the need for voice communication and completing the process 
with the Xpedite data network. Finally, as Xpedite gains wide acceptance the users of the system 
will uncover new and innovative ways to improve the system even further. 
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UNOS XPEDITE SYSTEM 



INPUT/OUTPUT DOCUMENTS WITH DESCRIPTIONS 

Following is a list of inputs and outputs for the UNOS Xpedite System with all related 
documents included in Appendix C. Each form in this appendix is separated with a 
numbered tab divider that corresponds to the item number shown below. This is an 
interactive system, as a result most input forms/screens are also output once data is 
included. 

The current manual donor registration form is included for reference. However, in the 
new Xpedite system the data captured is divided into three separate groupings, based 
upon the usefulness of the groupings, Donor Data, Lab Data and Organ Specific Data. 

INPUT ONLY 

1 . Intraoperative Management Form - provides data concerning the management 
of the donor during the organ recovery process and includes blood pressure, 
heart rate, medications dispensed with dosages and the time administered. 

2. Match Run Input Form - includes that data required to identify the donor by 
name and UNOS identification number plus donor demographics and the 
type of organs to be matched. This form also allows the user to establish the 
maximum number of candidates the match run output will provide. 



INPUT/OUTPUTS 

Donor Data 

3. Donor Registration Form - provides a compilation of data from several other 
form. 

4. Medical/Social History - provides for a complete medical and social history of 
the donor including 34 specific questions addressing previous health concerns 
and lifestyle issues 

5. Consent & Admission - provides data concerning the consent of Next of Kin 
for organ donation including the name, address, telephone number and 
relationship of the Next of Kin to the donor. Also included are the date and time 
of consent with a complete list of decisions for each organ 

6. Case Information - provides data concerning the managerial responsibilities 
for the donor including OPO and coordinator information, donor hospital with 
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attending' physician information, Medical Examiner case information (if re- 
quired), and information concerning the reason/circumstances of brain death 

7. Initial Physical Assessment - provides data concerning the original evaluation 
of the donor with specific evaluation of pulmonary, cardiovascular, 
intequmentary, gastrointestinal, genitourinary and musculoskeletal systems 

Lab Data 

8. Medications - provides historical information concerning the donor's 
medication usage and medications given to the donor during the 24 hour period 
prior to cross clamp 

9. Serology - provides specific blood study data on the donor including results of 
such tests as HIV etc. 

10. Pulmonary Data - provides relevant pulmonary data of the donor with fields 
for interpretation and comments by appropriate personnel 

1 1 . Microbiology - provides result of several relevant laboratory studies of the 
donor including 24 hour, 48 hour and final results of the studies 

12. Arterial Blood Gases - provides data indicating the results of relevant blood 
gas studies 

13. Cardiac Data - provides data concerning relevant heart information including 
EKG results and drug name and dosages provided to the donor 

14. CBC & Diff - provides data concerning the date time and results of additional 
blood studies from time of admission including red and white cell counts 

15. Chemistry - provides data concerning complete chemistry panel for the 
donor from the time of admission 

16. Hemodynamics/Tempurature - provides composite data concerning the 
donors blood pressure, heart rate, temperature and other relevant information 
from the time of admission 

17. Intake/Output - provides data concerning the volume of liquid and solid 
substances consumed by the donor and urine and non-urine discharge from the 
donor 

Organ Specific 

18. Lung Data - provides relevant data concerning the donor's lungs 
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19. Liver Data - provides relevant data concerning the donor's liver 

20. Kidney Data - provides data concerning the renal organs of the donor 

21. Heart Data - provides data relevant to recovery of the donor heart 



OUTPUT ONLY 

22. Match Run Output - provides information establishing the priority for 
acceptance or refusal of the organ being offered 

INFORMATIONAL 

23. Fax Memos - a series of fax cover memos indicating the data concerning the 
sender and recipient of the fax together with a checklist of documents from 
among the several above that are included with the fax 



i 
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PIECES 

PROBLEM-SOLVING FRAMEWORK AND CHECKLIST 
FOR THE UNOS XPEDITE SYSTEM 



The PIECES Framework is utilized as a determinant of the efficacy of the new UNOS 
Xpedite automated organ recovery system when compared to the current manual organ 
recovery approach. 

P erformance improvement are examined based upon throughput and response time. 

1 . Throughput improvements are central to the success of the new system. 
Currently, delays occur in disseminating collected donor information concerning each 
organ to the many transplant centers once priority is established for each organ. None 
of the donor data is maintained in any computer system. As a result, many times those 
organs that are most sensitive to deterioration (heart and lungs) cannot be utilized 
because of the long delays (potentially up to twenty-four hours) procurement 
coordinators experience in placing organs in greater demand (i.e. kidneys). With the 
new Xpedite System once donor information is collected via a laptop computer at the 
donor's bedside (currently done using the manual completion of paper forms), the 
coordinator transmits the information to the UNOS Matching system and all the 
transplant centers with priority candidates are notified electronically and simultaneously. 
Thus, necessary notifications that traditionally required several hours can now be 
completed in minutes. There are three components of this system that need to be 
examined from the standpoint of throughput: 

A - Procurement Coordinator - The amount of time required by the 
procurement coordinator to reach a point where a match run is initiated will probably 
increase initially for those coordinators that are not computer software/hardware literate. 
Other coordinators may likewise see throughput decrease until they have gained some 
experience with the system It is for this reason that UNOS will designate staff to provide 
a training assessment in prerequisite skills for coordinators. UNOS has also considered 
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pen-based input devices attached to the notebooks. To reduce the impact of lack of 
keyboard skills UNOS will provide training in utilization of Xpedite. These potential 
delays in the long run will reduce the time required by coordinators to initiate a Match 
Run. The additional throughput period will be from the time Match Run results are 
receive until the last donor organ is removed from the donor hospital. This time period 
may be cut by 50% or more. At the same time the number of organs placed is likely to 
increase. 

B. UNOS Organ Center - Throughput for the organ center will be cut to 
nearly zero due to the complete automation of the system and the elimination of staff to 
enter donor data into the computer, initiate the match run, and fax results to the 
procurement coordinator. 

C. Transplant Center - The throughput time for transplant centers is likely 
to increase as they will now have access to more data upon which to make decisions 
on the acceptance of an organ offer. As center official gain more experience in using 
the system throughput is likely to be comparable to that in the current system. 

2. Similarly response time has been a time consuming process. Often transplant 
centers have had to make decisions with incomplete information, which has resulted in 
an organ being sent that the center was then unable to use for the intended candidate 
(because of incomplete information at the time of acceptance). With the new system 
decision makers at transplant centers will have more complete, accurate and readable 
Donor Registration forms from which to render a decision. 



Information is the essence of the organ recovery process. The current manual system 

essentially requires all decisions to be made on the basis of faxed donor forms, which 
are most often incomplete, and verbal communications between the Procurement 
Coordinator and Transplant Center personnel. This information must then be 
communicated to other responsible decision makers at the center. The question is not, 
"Do miscommunications occur?" but in a system that is so critical to life, "Is there a 
better way to eliminate the possibility of miscommunication?". The answer is the new 
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system that places complete donor medical profiles directly in front of the decision 
makers. 

When this information is completed (as a result the procurement coordinator entering 
the data in a notebook PC with the Xpedite software) the coordinator transmits this data 
via modem to the Xpedite server at the UNOS Organ Center. Transplant center officials 
with a Skytel pager are notified of their priority. If center personnel have an Xpedite 
system they then go on-line and review the donor data and/or download the data to the 
center's system. For those centers without Xpedite these centers can dial into the 
Xpedite server and use the fax-back system to receive copies of the data forms. 

Economics or reduced costs is an additional benefit of the new system. Prior to organ 

recovery, donors are maintained in expensive critical care facilities during the 
placement process, which requires several hours and in some instances days. The new 
system reduces the time donors spend in expensive facilities which translates into lower 
costs. Additionally, by reducing staff time in the organ placement process costs are 
reduced. 

Control and security is insured by allowing only authorized purchasers of Xpedite 

access to the system. Passwords may be required at the user and system levels and 
donors and candidates are identified only by UNOS registration identification numbers. 
Once documents have been entered into the system, modification of the data is strictly 
limited with alterations documented for further tracking. Field systems backup is 
available on all systems and procedures at UNOS for system backup assure the 
protection of the data. 

Efficiency improvements are substantive in the Xpedite system. Reducing by several 

hours the amount of time required to place organs directly, translates into improved 
graft and patient survival. Further, the long term improvements in quality of life as a 
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result of lower ischemic (cold storage) time have been documented in several scientific 
studies. 

Service improvements are easily recognizable for the Procurement staff, Transplant 

Center personnel, transplant candidates and UNOS. Procurement coordinators perform 
their duties under extreme pressure. The more time that can be spent on donor 
management, and the less on paperwork and outside communication, the greater the 
probability of improved donor management. Transplant Center personnel with more 
accurate, timely, and readable information are better positioned to make critical 
decisions. Transplant candidates benefit as a result of the increased probability that 
organs will be recovered and that the organ is "right " for the candidate. Additionally, 
UNOS benefits by offering a technology that once again demonstrates their leadership 
ability in the transplant community. Finally, Xpedite will provide UNOS with a body of 
information and a database that does not currently exist. This data may provide untold 
clues to understanding the donor population of the U.S. transplant program. 
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Through SkyWord, we 

can let everyone know 

situation immediately," 

Mitchell explained. 
"Recently we 

enhanced our sys- 
tem through the 

Group Call Feature 

so that 50 key users 

can be paged with 

one message," Mitchell 

added. "This is a definite 

benefit because these 50 users 

can be paged simultaneously for the 

cost of only sending one message. 

Group Call is so important to us, 

we utilize it every day." 
With the Group Call 

Feature, a select group of up 
to 50 SkyWord users share 
one master PIN 
(Personal 
Identification 
Number). 
Messages can 
be sent to a 
group of SkyWord 
customers by utilizing the 
master PIN, while individual messages can 
still be sent through personal PINs. 



SkyWord 




THRE 



If E-Mail is the primary communication tool in your office, SkyMail 
can enhance the value of your E-Mail system by allowing you to easily 
integrate it with the SkyTel System. 



INTEGRATE LAN E-MAIL THROUGH SKYMAIL 



With SkyMail, LAN E-Mail messages 
can be directly addressed to your PIN 
(Personal Identification Number) or auto- 
matically copied to your pager upon receipt 
at your office E-Mail address. Either way, 
you'll receive messages on your SkyTel pager. 

SkyMail provides support for various 
E-Mail systems including cc:Mail™, 
■Microsoft* Mail, MCI Mail®, and AT&T 
Mail. SkyMail is easy to use and offers a 
number of business benefits. 

Flexible Messaging 

Choose the level of notification you desire 
based on the type of pager you carry and the 
amount-of information you want to receive. 
You can receive five-digit numeric messages 
on any SkyTel pager or 
various combinations of 
sender identification and 
E-Mail message text 
(up to 240 characters) 
on'SkyWord. 



selective 
Information 

If your E-Mail 
system allows 
message filtering, 
you can choose to receive 
notification of only those 
messages from your most 
important contacts. You'll be 



notified when your company's CEO or top 
customer sends an E-Mail message, while 
less urgent messages wait until you return 
to the office. 

INCREASED PRODUCTIVITY 

SkyMail allows you to stay in touch at 
all times. Whether you're on the road or 
waiting for an update before your sales 
presentation, you'll receive the information 
you need to make informed decisions. And 
if you travel out of coverage range, you can 
check your messages through Page Recall 
(Function 5 from the Paging Menu). 

For more information regarding SkyMail, 
contact your Sales Representative. 
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SkyTel's 

Computer Center 



Modem 





— LAN Gateway 



SkyTel offers around-the-clock customer service to meet your messaging 
needs. That means no matter what time zone you travel in, on any day of 
the week, you're guaranteed reliable answers to questions regarding SkyTel 
oducts and services. 



SkyTel's Unsurpassed Customer Service 



Providing unsurpassed customer service 
is a top priority at SkyTel. Whether your 
question concerns adding new products and 
services to your messaging plan, expanding 
your coverage options, or obtaining current 
account information, SkyTel Customer 
Service Representatives are available to 
help 24 hours a day, including weekends 
and holidays. 

And to ensure that you receive fast, 
efficient service, SkyTePs Voice Response 
Unit allows you to enter your PIN 

rsonal Identification Number) from a 
Jiephone keypad. The well- 
trained Customer Service 
Representative who takes your 

call will already have your 

account information in view 

and can assist you the moment 

your call is answered. 
Every SkyTel Customer 

Service Representative has 

fulfilled extensive training 

requirements. Classroom time 

and listening in on actual calls 

ensure that each representative 

is prepared to provide reliable 

answers each time you call. 
In addition to a knowledge- 

able staff of Customer Service 
wsentatives, SkyTel also has 
Specialized team of technical 

experts who'll assist you with 



Sky Word Access software interfacing, 
E-Mail integration with your SkyTel pager, 
and a myriad of other technical issues. 
This team can be reached directly at 
1-800-95-SERVE (1-800-957-3783) or via 
MCI Mail at the address EMS: MTEL 
GATE, MBX: SKYTECH® MTEL 

The next time you need assistance from 
SkyTel, call the Customer Service Team at 
1-800-SKY-USER (1-800-759-8737) or 
via MCI Mail address SKYUSER. You'll 
discover one more reason why SkyTel is 
the leader in global messaging. 




SEVEI 



/\s ousiness borders expand and trading partnerships develop around the 
world, SkyTel provides the international messaging coverage you need. 



M 



el Expands international Coverage 



Whether your company has international 
offices south of the border or in the Far East, 
SkyTeFs new coverage in Argentina and 
Malaysia makes it easier than ever to keep 
in touch when conducting business abroad. 




GLOBAL CONNECTIONS 

in the Far East 

Coverage in Malaysia creates one more 
link to the Association of Southeast Asian 
Nations (ASEAN) Region, forecasted to be 
one of the world's fastest-growing business 
areas over the next decade. 

Those who live and work in 
key business centers 
in the Far East, such as 
Hong Kong, Malaysia, and 
Singapore, can maintain a reliable 
connection to family and colleagues 
in the United States. 



Communicating South 
of the Border 

You can now take advantage of emerging 
market opportunities in Argentina without 
sacrificing the convenience of communicat- 
ing through SkyTel. Coverage south of the 
border is also available in Mexico, with 
plans to add Brazil, Colombia, Ecuador, 
temala, and Peru to the SkyTel System 

early 1995. 



SkyTel System 
Convenience 

While traveling in any 
internationally-covered 
country, you'll still enjoy the 
full range of SkyTel products 
and services. Your customers and colleagues 
will have a convenient link to you, and 
you'll save your company money by reduc- 
ing the number of international calls to 
the United States. 

SkyTel also offers three international 
coverage options: Simulcast Service, 
Follow-Me Service, and On-Demand 
Service, allowing you to choose the plan 
that best suits your messaging needs based 
on your international travel pattern. 

For more information regarding ) 
SkyTel s international coverage plans, 
call Customer Service at 1-800-SKY-USER 
(1-800-759-8737). 
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SkyTel Coverage locations 



CITIES COVERED WITH 
A POPULATION OF 
50,000 OR MORE. 
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Schenectady 

Smirhtown 

Suffolk 

Syracuse 

Tonawanda 

Troy 

Union 

Utica 

West Seneca 
Westchester 
White Plains 
Ywkers 

• NORTH CAROLINA 
Asheville 

Burlington 

Charlotte 

Durham 

Fayctteville 

Gastonia 

Greensboro 

Hickory 

High P«iint 

Raleigh 

Wilmington 

Winston-Salem 

• NORTH DAKOTA 
Bismarck 



Akron' 

Burlinj.'ron 

Canton 

Cincinnati 

Cleveland 

Gil um bus 

Dayton 

ElyTia 

Euclid 

Findlay 

Hamilton 

Kettering 

bkewood 

Lorain 

Mansfield 

Middietown 

Parma 

Sandusky* 

Steuhenville 

Toledo 

Youngstown 

• OKLAHOMA 
Norman 
Oklahoma City 
Tulsa 

• OREGON 
Corvallis 
Eugene 
Ponland 
Salem 

• PENNSYLVANIA 

Allentown 
Bethlehem 
Carlisle 
Erie 

Gettysburg 

Hanisburg 

Hershey 

King of Prussia 

Lancaster 

Philadelphia 

Pittsburgh 

Reading 

Scranton 

State College* 

West Chester 

Wilkes Bane 

York 

• PUERTO RICO 

Cajjuas Valley 
San ]uan 

• RHODE ISLAND 

Cranston 

East Providence 

Pawtucket 

Providence 

Warwick 

• SOUTH CAROLINA 
Chariest on 
Columbia 

Florence 
Greenville 
Hilton Head 
Mynle Beach 
North Charleston 
Spartanhur" 

• SOUTH DAKOTA 
Sioux Falls 

• TENNESSEE 
Bart leu 
Breniwtiod 
Chattanooga 
Johnson City 
Kingsport 
Knoxville 
Memphis 
Monistown 
Nashville 

• TEXAS 
Amarillo 
Arlington 
Austin 
Beaumont 
Brownsville 
Bryan* 

Girpus Christi 

Dallas 

Denton 

Edinhurc 

El Pas,. 

Ft. Wunh 

Galveston 

Garland 

Grand Prairie 

Harltngen 

Houston 

Irving 



Killeen 

Uredo 

LewisvilJe 

Lubbock 

McAllen 

Mesquite 

MidlanJ 

Mission 

Odessa 

Pasadena 

Piano 

Possum Kingdom 

Richardson • 

San Angelo 

San Antonio 

Sherman 

Tyler 

Waco 

Wichita Falls 

• UTAH 

Ogden* 
Orem 

Provo 

Salt bkeCity 
Sandy City 
West Valley 

• VERMONT 
Burlington 

• VIRGIN ISLANDS 
St. Thomas 

• VIRGINIA 
Alexandria 
Arlington 

Bailey s Gossroads 

Berryville 

Charlottesville 

Chesapeake 

Fairfax 

Fredericksburg 

Hampton 

Manassas 

Marina Toweis 

Newport News 

Noriolk 

Portsmouth 

Quant ico 

Richmond 

Roanoke 

Vienna 

Williamsburg 

Winchester 

Woodhrid^e 

• WASHINGTON 
Anacnnes* 
Bellevue 
Bellingham 
Everett 
Lakewood 
Olympia 

Seattle 

Spokane 

Tacemia 

Vancouvet 

Yakima 

• WEST VIRGINIA 
Charleston 
Huntington 
Wheeling 

• WISCONSIN 
Appleion 
Green Bay 
Kenosha 
Madison 
Milwaukee 
Oshkosh 
Racine 
Somers 
Watiwatosa 
West Allis 

- WYOMING 
Jackson Hole 

INTERNATIONAL 
LOCATIONS 

Argentina* 

Bahamas 

Bermuda 

Canada 

Hong Kong 

Malaysia* 

Mexico 

Singapore 

* New Coverage Locations 



Atlanta. Georgia 
Roston, Massachusetts 
Charlotte. North Carolina 
Chicago. Illinois 
Cincinnati. Ohio 
Cleveland. Ohio 



SkyTel Regional Sales Offices 



Columbus. Ohio 
Dallas. Texas 
Denver. Gdorado 
Detroit. Michigan 
Ft. Lauderdale/Miami, 
Florida 



Houston. Texas 
Jackson, Mississippi 
Los Angeles, California 
Minneapolis, Minnesota 
New York, New York 



Philadelphia. 

Pennsylvania 
Phoenix. Arizona 
Pittsburgh, Pennsylvania 
San Diego. California 



San Francisco, 
California 
St. Louis. Missouri 
Washington, D.C 



To receive extra copies of The SkvTV! L faw. call I .JW-SK Y-USER. Pien.se also let us knrnv ..|'anv address chan-vs. 
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APPENDIX B 



UNITED NETWORK FOR ORGAN SHARING (UNOS) 

GST FRAMEWORK 

INTERRALA TIONSHIP 



UNOS HHS, Div. of Transplantation 

UNOS Health Care Financing Administration 

UNOS"^^ Congress 

UNOS "*»«- Transplant Centers 

UNOS "«»«- Transplant Suregons 

UNOS -*«»- Transplant Coordinators 

UNOS ■«»«■ Organ Donors and Families 

UNOS -«>«- Organ Procurement Organizations (OPO) 

UNOS "^"^ Donor Organ Recovery Teams 

UNOS^^ Donor Hospitals 

UNOS Professional Societies and Associations 

UNOS "•»•*■ Transplant Recipient Advocacy Groups 

UNOS "■>•- Scientists and Researchers 

UNOS"®®' Medical Professionals 

UNOS Major Pharmeceutical Manufacturers 

UNOS Major Pharmacies 

UNOS Transplant Recipients 

UNOS^^" Public 

UNOS^^- Media 



Organ Donors and Families OPO 

Organ Donors and Families Donor Hospital 

Organ Donors and Families "*«»- Donor Organ Recovery Teams 

Organ Donors and Families Transplant Recipient Advocacy Groups 

Organ Donors and Families Transplant Recipients 

Organ Donors and Families "^"^ Media 



OPO Donor Hospitals 

OPO Donor Organ Recovery Teams 

OPO *w Transplant Centers 

OPO -«>«»- Transplant Suregons 

OPO "^^Transplant Coordinators 



OPO Professional Societies and Associations 
OPO "^^Transplant Recipient Advocacy Groups 
OPO Transplant Recipients 
OPO Public 
OPO Media 

Transplant Recipients ^^Transplant Centers 

Transplant Recipients ^^Transplant Suregons 

Transplant Recipients ^^Transplant Coordinators 

Transplant Recipients Transplant Recipient Advocacy Groups 

Transplant Recipients Medical Professionals 

Transplant Recipients Major Pharmacies 

Transplant Recipients Public 

Transplant Recipients ^^Media 

Transplant Recipients Donor Hospitals 

Transplant Centers^^HHS, Div of Transplantation 

Transplant Centers ^^Congress 

Transplant Centers ^^Transplant Suregons 

Transplant Centers ^^Transplant Coordinators 

Transplant Centers "^^Professional Societies and Associations 

Transplant Centers ^^Transplant Recipient Advocay Groups 

Transplant Centers ^^Scientists and Researchers 

Transplant Centers Medical Professionals 

Transplant Centers ^^Major Pharmeceutical Manufacturers 

Transplant Centers Major Pharmacies 

Transplant Centers Public 

Transplant Centers ^^Media 

HOLISM 

Government 
Transplant Centers 
Transplant Suregons 
Transplant Coordinators 
Organ Donor and Families 
OPO 

Transplant Recipient Advocacy Groups 
Transplant Recipients 



GOAL-SEEKING 



Return chronically ill patients to productive and fulfilling lives 

Profit 

Reseach 

Enhance image of Hospitals 
Decrease deaths 

INPUTS 



Patients 
Money 
Doctors 
Suppliers 
Organ Donors 
Laws 

Regulations 
Taxes 
Interns 
Residents 
Trauma Victims 

TRANSFORMATION 

Contracts and Grants 
Education 
Member Services 
Policy Development 
Research 
Business 
Development 
Communications 
Computer Services 
Planning 

Committee Liasions 
ENTROPY 

Untimely Organ Matching 

Deaths 

Lawsuits 

Dissastisfied persons ( candidates, recipients, members, govt, representatives, etc.) 
Unused Organs 



OUTPUTS 

Patients with improved health 
Employment 
Deceased patients 
Discarded organs 
Research 

Improved procedures 
Laws 

Regulations 
Educated doctors 



Transplant Center Operations 
Procurement of Organs 
Patient Requests and Priorities 
Organ Removal and Security 

Donor and Recipient Medical History and Assessment 
On-line and Download Donor Data 



REGULATION 

National Organ Transplant Act (NOTA) 
National Anotomical Gift Act 
State donor laws 

Restriction from local Medical Examiners 
Federal regulation 
Federal Contracts 

Unos Board of Directors' adopted policies 

HIERARCHY (Organizational Chart enclosed) 

Public 
Congress 

HHS, Div. of Transplantation 

Unos Members 

Unos Board of Directors 

Unos President 

Executive Director 

Asst. Executive Director 

Functional Areas 

DIFFERENTA TION 

Contracts and Grants 

Education 

Member Services 

Policy Development 

Research 

Business 

Development 

Communications 

Computer Services 

Planing 

Committee Liasions 
EQUIFINALITY 

Transplant candidates receive transplant and live or die 

Transplant candidates do not receive transplants and die 

Transplant Recipients become productive or remain dependent on others 



INTRAOPERATIVE MANAGEMENT 



I KJf~^Q United 

W NWa^Of Organ Sharing 



OIS 10:000201995/01/23-11303:31 



UNOSID: 



Donor Nam*: Mary Doe 



OR Data/Tim*: 
Dafta/Tlrm: 



Exit OR Data/Tlma: 
> Data/Dm*: 







Low 


Duration 


Hgh 


Duration 


BP 












MR 













Last Hour UHna Output: 
Total UrirM Output: 



oc/hr 

cc 

cc 



MEDICATIONS 



Drug Nam* 


Doaaga 


Tkna 













































U Vaaodllatom 
0 Vaaopraaaora 



Drug 


Doaaga 


Tlma 

































BLOOD PRODUCTS 



CRYSTALLOIDS 



Typ. 


VoiWM 







Comments: 



OR TEAMS 



Heart 


HearVLung 


Rtght Lung 


Uft Lung 


































Liver 


KJdneya 


Pancreas 


iniestlne 


































Aneetheela 


Circulator 


Scrub* 


Other: 



























Bacjimtpj intemaiten 

Mfn* composed: 01/23/95 02:52:53 PM 
Original Document Author: Audrey Nellsen/UNOS 
Author Access OtS Organ Center; Audrey Neiben/UNOS 
Reader Acceee: Audrey Neiben/UNOS; UNOS 



MATCH RUN INPUT 



^J^^^^Uniled Network 



for Organ Sharing 



OIS 10: 000201995/01/23-1 1 :03:31 



UNOS ID: IAW054 



Donor Nam*: Mary Doe 



LOCAL INPUT VARIANCES 



OPO Confer CooV GAMC 
Donor Hospital Zip Gods: 23456 



User Initial*: AN 

Donor Age: 25 
Donor Weight: 120 
Donor Might GO 
Donor Race: White 
A1:10 A2: 10 
ABO: A1 

Match Run Organs: 



B1: 14 



B2: 14 



Donor Canter Name: ModcaJ College Of Georgia Hosprtal 
Donor Provider Number: 



Donor Age Unit: Years 
Donor Weight Unit: Pounds 
Donor Htlght Unit: Inches 
Donor 8ex: Female 
DR1:5 DR2:5 



HR. Kl, U, LU, PA. IN. HL, KP 



Is There Time to Run s Cross Mstch? No 

Previous Osstrolntestinai Disease: No 

How many Unas (Including headers) of the 
would you like to have Initially available? 



Kidney Side Code: Both 
Should Tray Data Be Used? No 



Hepatitis Positive: Negative 
Run Output 



Organ 


Default Number of 
Output Unas 


HR or HL 


so 


Kl 


100 


U 


50 



Organ 


Default Number of 
Output Unas 


LU 


50 


PAorKP 


50 


IN 


30 



Document lntomik>p 

DeWTlme composed: 01/23/95 01:17:39 PM 
Document Author: Audrey Neseen/UNOS 
Match Run Status: SUCCESS 
Reason Why Match Waa Re-Run: 

Author Access: 

Reader Acoees: Audrey NeisanAJNOS; UNOS; OIS Organ Center; Audrey NeisanAJNOS 



0C7£ 



Ot*T 



LNOS 



i 1 i 

DONOR WFORMATJON .noT^— J 



CcnuaPcun 



c 



O SE0PF D SIX ANTIGEN DKEGION 2 n ™ 

n« • r-l „ a ACTIVE EXTRARENAL D POINT SHARE 

□ Retrieval □ Import nPavfian, rV 

fi— Pay Back UOmanR^i □ Tissue Only Referral 

■ OPO Case # it ^^ 

MedRec# 



Recovery Date 



Coordinator Name 



Donor Hospital 
City/State t 



DONOR INFORMATION 



Date/Time Admission 
Date/Time of Referral 



Telephone # 



Provider No. 




. Hosp. Unit 



Oonor Name 

SSN 

Age 



_ Attending Physician 
Referring Person 



Sex 



Date of Birth 



Race 
Ht. 



Wgt 



. ABO — Sub — HLA A b DR 

| Home City 

Home St **- Citizenship " 

Zip Code _ 




Cause of Death 



Autopsy □ yes □ no 

Death Pronounced □ yes □ no MD 

Method 

Date 



. Time 



Medical Examiner/Coroner's Case □ yes □ no 
W yes, ME Restrictions/Denial 



Corner, was obtained to a» organs? □ , es Q no » no. reason 

STo,r^^ nM?D ^ D ~°~ 

NOK address: 

Consent given for organs: 
Consent given for tissue: 
Consent for research: 



Name of ME/Coroner 
Time of ME Contact 
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DRAFT 8 



Patient Name 



UNOS ID # 



INITIAL PHYSICAL ASSESSMENT 




PULMONARY 

TUBES: 



Date 



Time 



D Endotracheal □ Tracheostomy □ Left Chest □ 



Right Chest 



BREATH SOUNDS: D even 
□ clear 

CARDIOVASCULAR 
UNES: □ PA ceth 

HEART RHYTHM: 
HEART TONES: 
PERIPH. PULSES: 
PERiPH. EDEMA: □ present 



□ 



uneven 



□ 



ebeent left/right 



□ regular 
norma! 

□ present 



D rales left/right □ rhonchi left/right 
D Arterial line 



QASTTONTESTKAL 

DPI: 
TUBES: 
ABDOMEN: 



□ cvp 

□ irregular 

□ murmur 
12 3 4 
12 3 4 

□ no 

□ gastronomy 
D surgical ecars 
Dfirm 

bowel eds □ no bowal ads 



drub 
□ absent 
Oabeenl 



SKIN 
Qpink 
O warm 

bruises 
□ tattoos 



□ dusky 

□ cool 

□ lacerations 
track marks 



Temperature _ 
□ abrasions 



□ n 0 

□ incisions 

□ soft 



Result 

□ surgical drains 

□ other scars (describe below) 

□ non-distended □ distended 



GEMTOUWNARY 

URINE VOLUME: □ < 1 00 cc/hr 
APPEARANCE: □ clear 

MUSCULOSKELETAL 
FRACTURES: □ cloeed 



□ 100-500 cc/hr 

□ cloudy 



□ > 500 cc/hr 
hematuria 



□ 



anunc 



I compound/open 



□ 



d re Mings/splint* 



□ 



Traction 



□ 



Please identify arty injuries, fractures, incision., tattoos, social indicators on the diagrams end describe below 
Please discuss hospital history (include injuries, arrests. OR procedures, infections, etc.) 
U Cardiac/Re«piratory Arrest (downtime) 

□ Chest compressions (time) 

□ OR Procedures 

□ Defibrillation 
Comments: 
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DRAFT 8 



Patient Name UNOS ID # 



MEDICAUSOCIAL HISTORY 



lease complete. Any YES ftquiw detailed explanation In comments eection including frequency, duration. recent history, and additional comments. 



Ha* tha patent had a history of: 


YES 


NO 


UNK 


COMMENTS 




1 . Uver Disease 












Hepatitis 












| Cirrhosis 












2. KSd nay Dtaaaaa 












3. Hypartanaion 








Duration: 




4. Heart OiaaaM 












5. Oiabataa 








Insulin Q YES 0 NO 




6. Cancar 












7. Neurological Diaeaaa 












Meningitis 










Dementia 












6. Pulmonary Disease 












TB 












9. Previous Surgery 








■ — 


Type and Date 










10. Drug or Subetance Abuse 












rv 












ETOH 












Tobacco 








# packs per dsy 


U 1 1 : Received Previous Blood Transfusion 








Year 


12. Received Human Pituitary 
Growth Hormone (Pit-hgh) 










13. HomoeexuaVBiaexuat/High 
HfV Risk Sexual Partner 










14. Unexplained Weight Loea/Recent 
Flu-like Symptoms 










Persistent Diarrhea 










15. Immunized/Vaccinated Last 6 Months 










16. Auto-immune Disease 










I 17. Persistent Cough or Fever 










| 16. Allergies 










| 19. Arthritis or Joint Disease 










20. Prolonged Steroid Use 










21. Other pertinent medical information (under comments) 


PersonaJ PhysWane name: rw«. Occupation 
Respondent name: ^imii^hip 
Medications: 



Comments: 
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DRAFT 8 



Patient Name UNOS |Q # 



1 ' 

t 






LAB PROFILE 


LAB DATA 


ao mil 








Final 


1 URINALYSIS 


Initial 




Final 


CBC& 
Drff 


Admit 




Final 


Date 












1 Oats 








Data 








Tims 












1 Tim* 








Time 




















1 Color 








RBC 




















1 Appaaranca 








wBcjr^o 




















I pH 








SeQs 








BUN /o-lj" 












1 Spac. Grav. 








Lymphs 








Creatinine^Y,^ 












1 Protein 








Bands 








Glucose 7^ 












1 Glucoaa 








Monos 








CeJcium 












| Blood 
















Phosphorus 












1 RBC 








Eos 








Bilirubin • ' mm ^ t 
(tot/dir) 












WBC 
















SGOT/AST5^ 












Epith. 
















SGPT/AlTi\J5- 












Caste 
















GGT -J J 












Bacteria 








Hct^-j-t 








Mg + + 












Comments 


Platelets 








Mk Phosxo- ft? 


















































PTT 2-O.jr 














CPK (tot/MB) 


/ 


/ 


/ 


/ 


/ I 




Amylase - *4C 














Lipass 














SEROLOGY 


MICROBIOLOGY j 


+R~Raectfve 


NR-I 


Mon-Rasi ctiva 


CULTURES 


DATE 


RESULTS 


N/A«Not Appficafab 


PRE 


POST 


Blood 






Date/Time 






Blood ~~ — _ 






Anti-HIVl 






Urine 






Anti-HIV II 






Sputum 






Antt-HTIV 1 






Sputum Gram SUin 






Anti-HTLV II 






CSF 






RPR-VDRL " ~ 






R Ureter 






Anti-CMV 






L Uratar 






HEaAg 






Kidney Slush 






Anfr-HBC 






Othar 






Vn^HCV 






Comments: 


Jther 








Other 
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DRAFT 8 



Patient Name 



UNOS ID # 



HEMODYNAMICS/TEMPERATURF 




INTAKE 



Descriptive 
note when 
not a 24- 
hour total* 



Date 



OUTPUT 



Crystalloid 
Amount 



Colloid 
Amount 



Blood 
Products 
Type/Amt 



24 hr 
Total 



/ 



Hourly 
Average 



24 hr. 
Urine 
Output 



Other 
Amt: Non- 
Urine 
Output 



24 hr. 
Total: 
Urine & 
Non-Urine 
Output 



Lowest 
U.O. per 
hour & 
duration 




INOTROPIC SUPPORT 




DRAFT 8 



Patient Name 



UNOS ID # 



CARDIAC DATA 



See page 10 □ YES □ NO 



£KG 

Date/Time / I nterpretation 



Consulting Physician: 



ECHO 
Date/Time 
E/F \ 

CVP 

Drug 



. Interpretation 



BP l_ 



HR 



Dosage 



Heart Rhythm 



Pressors □ YES □ NO 



Consulting Physician 



ANGIOGRAPHY 

Date/Time f_ 



^Interpretation m 



Consulting Physician 



Use page 10 if more space is required for interpretation 



PULMONARY DATA 



J Interpretation/Comment 



CXR Date/Time 

Change from previous CXR O yes D no 

CXR Date/Time ]_ Interpretation/Comment 



Change from previous CXR D yes D no 



CHEST MEASUREMENTS 

fttOm LUNQ LEFT LUNO 




1. 
2. 
3. 
4. 
5. 
6. 



Length of Right Lung 
Length ot Left Lung _ 

Aortic Knob Width 

Diaphragm Width 



Chest circumference/Landmark 
Distance from RCPA to LCPA 



RCPA**i« LCPA 



ARTERIAL BLOOD GASES 



Date/Time 



PH 



pco. 



pO. 



HCO, 



0 2 Sat 



FiO, 



Rate 



TV 



PEEP 



Hgb 
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Patient Name 



UNOS ID # 



MEDICATIONS 

Ust ALL medications other than inotropes given during hospital course and donor management 




Date/Time Stopped 



Total Amount 



Comments 



INTRAOPERATIVE MANAGEMENT 



Incision Dste/Time 
Clamp Date/Time 
Exit OR Date/Time 



. Circle Zone (EST) (CST) (MT) (PST) 
. Circle Zone (EST) (CST) (MT) (PST) 
. Circle Zone (EST) (CST) (MT) (PST) 



Average BP: 

Average HR; m 

Average Urine Output 



. Low BP: 
Low HR: 



Duration: 
Duration: 



cc/hr Laat Hour Urine Output 



□ Heparin 
Thorazine 
Mannrtol 



□ SoJumedro! 
O Other 

□ other 



Dosage 
Dosage. 
Dosage # 
Dosage _ 
Dosage m 
Dosage _ 
Dosage _ 



□ Vasodilators 
Q Vasopressors 



□ 



. High BP: m 
. High HR: " 



Duration: 
Duration: 



cc/hr Total Urine Output in OR 



Drug 
Drug 
Drug m 
Drug m 
Drug m 



Dosage 
Dosage 
Dosage 
Dosage 
Dosage 



Blood Products Type/Volume. 



Comments: 



a 
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Patient Name 



UNOS ID # 



ClamP Time Circle Zone (EST) (CST) (MT) (PST) Warm Ischemic Time □ yes □ no Duration 

isitu Flush □ yes O no Flush Solution Volume Flush Characteristics 1 + 2+ 3+ 4+ 

Storage Solution Backtable Flush □ yes □ no En Bloc □ yes □ no 

Typing Materials: □ Nodes □ Spleen □ Blood Clot □ Cell Prep □ T Cell □ B Cell 



LEFT KIDNEY ANATOMY 


RIGHT KIDNEY ANATOMY 


□ Txp LlRsrch □ Disc □ Not Recovered 




□ Txp □ Rsrch □ Disc □ Not Recovered 


Comments 


cm 


length 


cm 


Comments 




cm 


width 


cm 






weight 








# arteries # 






cm 


cm 


cm 


length 


cm 


cm 


cm 






mm 


mm 


mm 


diameter 


mm 


mm 


mm 






disfanrp anart 








aortic cuff 








# veins # 






cm 


cm 


cm 


length 


cm 


cm 


cm 




g 


mm 


mm 


mm 


diameter 


mm 


mm 


mm 






distance apart 










cava! cuff 






# ureters # 




I 


cm J 


cm 


ureter length 


cm 


cm 





LEFT KIDNEY 




Biopsy DyesDno 
Comments 



LEFT 


RENAL ANATOMY 


RIGHT 


Dy-Dno 


Aortic plaque 


Oy«sO no 


□ y-Dno 


Arterial plaque 


□ y-Dno 


□ y-Dno 


Infarct ed area 


O y**0 no 


□ y-Dno 


Capsule intact 


□ y-Dno 


□ y-Dno 


Subcapsular hematoma 


□ y-Dno 


DywDno 


Cysts/discoloration 


D y-Dno 



RIGHT KIDNEY 




Biopsy D yes □ no 



Comments 



Patient Name 



UNOS ID # 



HEART DATA □ Transplanted □ Valves □ Research □ Discarded □ Not Recovered 



Cardioplegia 



Solution 



Anatomical Abnoonality □ yes □ no Comments 

Surgical Damage □ yes □ no Comments 

Recovering Surgeon 



Volume 



LUNG DATA □ Transplanted □ Research □ Discarded □ Not Recovered 

Lung Recovered □ Right □ Left □ Heart/Lung □ Double Lunq 
F,us * Sta " - Solution 




Surgical Damage □ yes □ no Comments:^ 

Anatomical Abnormality □ yes □ no Comments: 
Recovering Surgeon 



PANCREAS DATA □ Transplanted □ Islet Cells □ Research □ Discarded □ Not Recovered 
Flush Start —=—=_ 



Solution 



Volume 



Whole □ yes □ no Celiac □ yes □ no Spleen attached □ yes □ no Portal □ yes □ no Other 
Anatomical Abnormality □ yes □ no Comments 
Surgical Damage LJ yes no 
Recovering Surgeon 




UVER DATA □ Transplanted □ Research □ Discarded □ Not Recovered 



Aortic Flush Start Time 
Portal Flush Start Time 
Precool Start Time 

Surgical Damage 

Biopsy 

Vessels Sent 



m Solution 
„ Solution 
. Solution 



□ yesD no Comments: 

□ yesD no Comments: 

□ yesD no Comments: 

Gall Bladder Incised dyesDno 

Gall Bladder Flushed □ yes □ no Solution 
Recovering Surgeon 



m Volume 
_ Volume 
Volume 



.Char 12 3 4 
.Char 12 3 4 



Volume 



I TISSUE DATA 


RECOVERED 




TECHNICIAN/TISSUE BANK 




YES 


NO 


EXPLANATION IF NO 




Corneas/Eyes 










Skin 










Bone/Tendon 










N Saphenous Vein (indicate #) 










Heart Valve 










p Other 
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MEDICAL/SOCIAL HISTORY 



I k I/^Q United Network 
V-J ^l\wA3f<*' Organ Sharing 



as ID: 00020- 1995/01/23-1 1 D3.31 



UNOS ID: 



Donor Name: Man/ Doe 



Relationship to 



Do you flseJ that you know the 
w dlcd froc ta l rdatory? 

HYPERTENSION 
Htotory of Hypertension: 



Msthod of Control 

»•(: Diuretics: 

Mstory of Dlsbetes: 
Insulin Dependent: 

CHEMICAL USE 
History of Ogeretu Um: 

(> 20 Pack Years) 

Nbtory of Alcohol Dependency: 



wsfl enough to snswsc 



Duration: 
now tong r 



fVDrug use: 



Other Drug Use: 



CArJCEfl 
Htetory of Oanosr : 

Location of Canosr: 

Cancsr at Ttm* of Procursmsnt 
Intracranial: 



Duration: 



Othar Hypertensive Medication: 



Extracranial: 



Contfnuad Cigarette Uas: 

(Last 6 Months) 

Continue Alcohol Uas: 
(Last 6 Months) 

Continued IV Drug Uas: 

(Last 6 Months) 

Continued Othsr Drug Uaa: 

(Last 6 Months) 



Canosr Free IntsrvaJ: Yaars 
If Othsr, Spsclfy: 

8Un: 



QUESTIONS 


ANSWER 


COMMENTS 


1. Did ths dsoaasad have any history of heart disease, high 
blood pressure, or chest pain? Poor circulation espedatty in the 
lags? Take any drugs tor heart or B/P problems? If so, what? 






2. Did the deceased suffer from any type of Uver disease? Any 
history of yefiow Jaundtoe? Been toid they had type of Hepatitis? 
Any contact with parsons diagnosed with Hepatitis? 






3. Ott the deceased suffer from any type of neurological or brain 
dbease such as Alzheimer's, seizures, periods of oonfusion or 
recent memory loss, history of brain tumor? 






4. Did the deceased have any KWney rates* disease? Kidney 
stones? Frequent infections? Ever been treated with Kidney 
dialysis? 


• 





5. Did the deceased have a history of diabetes? How many 
years? Required oral medication or insufln injections? How 
many years? 






6. Did the deceased have a history of digestive or intestinal 
fwuomms r ever nave otoooy sooocs or mtesonai surgery? 






7. Did the deceased have any hfatory of arthritis or Joint disease? 
rssnry w oronen oones r Any complaints oi sot or sore Jo bits 7 






8. Did the deceased have any history of asthma, emphysema, or 
■ny wng osease r ever nave a positive skin lest lor 
Tuberculosis? Ever treated tor TB? 






rias me oeoeaseo oeen seen oy a pnysictan or nosprtailzed in 
the past two years? What physician and/or what hospitai? 






10. Has the deceased ever had cancer or received radiation 
therapy or drugs for cancer? 






1 1 . Has the deceased ever had any past surgical procedures? 
Please name them. 






12. Has the deceased experienced any periods of explained or 
unexplained weigh loss? 






13. Did the deceased ever use WegaJ drugs or other 
substances? (i.e., cocaine, marijuana) 






14. nas tne deceased ever received blood transfusions or blood 
products prior to this admission? 






15. Has the deceased ever been refused as a blood donor or 
told not to donate? Why? 






16. Did the deceased ever receive an organ or tissue transplant? 

it a Lvui /wmao Akin i^u _ . \ 

rone, corns a. sign, nean, Udney) 






17. In the past 12 months did the deceased have a tattoo, ear 
pwang. acupuncture, or acooentai neeote sock? 






18. Was the deceased vaccinated tor Hepatitis B? 






1 9 fn the past 4 weeks was the deceased vaccinated tor any 
reason? 






20. Was the deceased ever given growth hormone? 






21. What medications, if any did the deceased take on a regular 
basis? 






22. Did the deceased use tobacco products? Cigarettes? 
Packs/day? For how long? Other tobacco oroducts? 






23. Did the deceased drink alcohol? How much? What type? 
For how long? 






24. Has the deceased ever been exposed to toxfc eubetance? 
(i.e., lead, pesticides) 






25. to the past 12 months, was the deceased diagnosed with or 
tested tor syphttts or gonorrhea, or have a reactfve screening 
lest tor syphilis in the absence of a negative confirmatory test? 






26. Has the deceased ever been In fat? tf so. how tong and 
where? 








27. Has the deceased ever been in a long term care tactirty? II 
so, how long and where? 






28. Has the deceased ever engaged in aex tor money or drugs? 
Did the deceased ever have sex with anyone who had? 






». Male Dorm: Has the deceased ever had aex with another 
male even one time? 






30. Female Donors: Has the deceased ever had sex with a male 
who has had sex with another male? 






31. Has the deceased ever used a needto to fc*»ct drugs into 
their veins, muscle, or under their skin far nonmedical use? Did 
deceased ever have sex with anyone who had? 






32. Did the deceased ever have sex with a person known or 
wopec»a id nave niv inecoon? 






33. Has the deceased ever received dotang (actor concentrates 
tor hemophilia or other bleeding disorders? Did the deceased 
ever have sex wtth anyone who had? 






34. Was the deceased ever exposed to known or potentially 
HIV-infected blood through accidental needle-stick or through 
contact with an open wound, non-intact skin, or mucous 
membrane in the past 12 months? 







ADDITIONAL COMMENTS (pteese refer to the question numbers where applicable): 
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CONSENT & ADMISSION 



I k I/^C Un « ted Network 
KJ NV^Ofor Organ Sharing 



CMS ID: 0002a 199S01/23- 11 A3 31 



UNOSID: 



Donor Nam*: Mary Doe 



Date of Conaent: 01/1 5795 
Time of Consent: 08:00 PM 

NEXT OF KIN INFORMATION 
Nam*: Joe Doe 

Ratottooahip to deoeaaed: Brother 
Address: 1 Main St 
Phons (804)555-1212 
Funaraf Home: Biile/s 
Discussion: Yes Permteeion: Yes 



Approechad by: Social Worker 
If other, pJeaae apacffy : 



Donor Card: Yes 



Tteaue Tranaplant: Yes 



Reaea rc h Conaent: No 



Tfcesue Bank Name: Donl know this one 
Tlaaue Bank Coordinator: Mary Smith 



Organ 


Consent 
Requested? 


Wrtte Reason H conaent 
Not requested 


Conaent Obtained? 


Enter Reason 
Code If No 


Specify H Other 


Kidney 


Yes 




Yes 






Uver 


Yes 




Yes 






Intestine 


Yes 




Yes 






Pancreas 


Yes 




Yes 






Heart 


Yes 




Yes 






Lung 


Yes 




Yes 






Tissue 


Yes 




Yes 







Admission Course/Comments: 



Cardlac/ReepJretory Arrsat 



Downtime: 



ID 



Chest Compraaalorta 



Duration: 



[D 



OR Procaduiaa ' 



Comments: 



[D 



Defibrination 



Comments: 



Body Diagram 

Lookup Key: Man 



Hidden Fields 



Diagram 



Additional Atrntrntnt Comments: 

Qflcumtfll Inrvmtiton 

Date/Time compoMd: 01/23/95 01 .09:57 PM 
Original Document Author: Audrey NeiJsenAJNOS 
Author Accms: OiS Organ Center; Audrey Neilsen/UNOS 
Reader Access: Audrey NeiiservTJNOS; UNOS 



CASE INFORMATION 



I Kjf"Y2 Unitcd Networic 
w N V_A3for Organ Sharing 



[as ID: 00020-1805^1/23-1103:31 


UNO6I0: 


Donor Name: Mary Doe 


9 LocaJ 
0 Non Local 




0 Referral Only 

0 Contented But Not Recovered 
0 Recovered 




9 Organ Referral Only 
0 Tissue Referral Only 
0 Organ a Tissue Referral 





Referral Call Date: 01/13*5 
Recovery Date: 01/15*5 
Medical Record f : 12345 

QPO and COORDINATOR MEQBMADflM 

First Coordinator's Name: Audrey Neilsen 
Secondary Coordinator^ Name: 
OPO Provider #: 11p001 
OPO Center Code: GAMC 

HOSPITAL INFORMATION 

Admission Date: 01/10*5 
Admission Time: 02:30 AM 



Referral Call Time: 01 X>2 PM 



First Coordinator's Phone #: 804-330-8636 
8econd Coordinator^ Phone #: 
OPO Name: MEDICAL COLLEGE OF GEORGIA HOS 



Attending Physician: Dr. Spock 
Referring Person: 



Provider #: 11 pO0 1 
aty: AUGUSTA 
Unit: leu 

MEDICAI FXAMINFRTAgP 

M.E. Contact Date: 01/14*5 
M.EVCoroner Case: No 
M.EJCoroner*e Name: John Doe 
M.E. Restrictions/Denial Reasons): 

flBAIN DEATH 

Cause of Death: Head Trauma 
Other Cause of Death: 



Name: MEDICAL COLLEGE OF GEORGIA HOS 
8tate: Georgia Zip Code: 30912 

i*: (804)555-1212 Fax*: 



M.E. Contact Time: 10:00 PM 
M.E. Permission for donation: Yes 
M.E. Case #: 23456 



Mechanism of Death: Blunt Injury 
Circumstances of Death: 



Brain Death 
Brain Death 


Pronounced: Yes 
Methodfe) Used: 




y: No 




MD 


Brain Death Data 


Brain Death Time 


First 


something here 


01/14*5 


07:00 PM 


Second 









MEECJKHi 
CaWcal Infection: No 

W Yes, Complete the fonowtng: 



1 Source 



Oontrtned by Cuftura? 



D Blood 






LI Pulmonary 




ID Urine 
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INITIAL PHYSICAL ASSESSMENT 



LNOS 



United Network 
or Organ Sharing 



I OIS 10:00020-1995/01/23^1:03:31 



UNOSIO: 



Donor Nam*: Mary Doe 



AmmmmiiI Complttlon Oatt: 01/23/95 
A«WMmwl CompfeUon Tana: 02:05 PM EST 



PULMONARY 
Tubaa: 



Endotracheal: 



81m: 



LaflChaat Tub*: 

Breath Sound*. 
CAflPrOYA&CUlAR 



Tracheostomy: 
Wght Ch**t Tub*: #; 



Heart Rhythm: 
P*riph. Puftaaa: 

fiTEQUMENTARY 

Color: 

Observations: 

QASTROIMTESTIN^ 
DPL: 

Tubas: 



Heart Toots: 
Periph. Edema: 

T#mp: 
RmuH: 



Tamp Reading: 



Abdomen: 



M Other Bcsre, Explain: 



GENITOURINARY 
Urine Volume: 

MVSCU1PSKFI FTAI 

Fracture •: 



Appearance: 



Document mfc^fltjon. 

Date/Tiro* compoMd: 01/23/95 02:03:33 PM 
Original Document Author: Audrey NeiisenAJNOS 
Author Access OIS Organ Center; Audrey Nertsen/UNOS 
fleadar Access: Audrey NeiisenAJNOS; UNOS 



MEDICATIONS 



I W |/^\C United Networlc 
LJNv^/Ofor Organ Sharing 



«S ID: 00020-1995/01/23-1 1:03:31 



imosio: 



Donor Nam*: Mary Doe 



llaflcatfon. 


Date 


Tkna 


Doaaga 


PaakDoaaga 

and Duration 


Dato8topp«d 


Tim* Stopp* 







































































































































































































Medications Given to Donor 24 Hours prior to cross clamp 



Antiarrythmlcs 




Anticonvulsants 




Antfhyparfanal vaa 




Antibiotics 




Vaaodllatora 




Vaaopraaaom 




Dopamtoa 





Ono 

0 Unknown 



Donor Pmi regiment 

DW donor receive pr e tieetmenl medic etkm? 



M Yes, Complete the following: 



Steroids 




Diuretics 




Thyroxin* 




Heparin 













Pbsmmoi totamatten 

Dste/Ttme composed: 01/23/95 02:4758 PM 
Origin*] Document Author: Audrey NeJfsen/UNOS 
Author Access OIS Organ Center; Audrey Neiben/UNOS 
Rssder Access: Audrey Neilsen/UNOS; UNOS 



SEROLOGY 



for Organ Sharing 



OIS ID: O002O~1995A)1/23-11 0331 



UNO6I0: 



Donor Nam*: Mary Doe 



Pre Transfusion Post Transfusion 



Anti-WVI 



AnU-HV II 



Antt-HTLVI 



Antl-HTLV II 



RPfl-VDRL 



Antt-CUV 



HBaAg 

Anti-HBC 



Antl-HCV 



Document tntomatlon 

Pata/Tlma cocnpo— d: 01/23*5 02:3303 PM 
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TISSUE DATA 



I k |/^VC United Network 
LJNV_/^for Organ Sharing 



as ID: 00020- 199S01/23-1 1 03:31 



UNOSID: 



Donor Name: Mary Doe 



ConwM/EyM 



FUco**r%d 



Explanation, If No 



Technician 



Tleaue Bank 



8idn 



Bona/TerKfon 
8aphanoua Vtan # 



Heart Vafve 



Ottiar 
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1 



URINALYSIS 



LNOS^" edNWV ™* 



for Organ Sharing 



OtS 10: 00020-1995/01/23-11103:31 



UNO6I0: 



Donor Nam*: Mary Doe 





I. IWHI 


9% 

2. 


3. 


4. 


5. 


6. 


7. 


Daw 
















— 

Tim 
















Color 
















Appaaranca 
















































Protein 
















GIUCOM 
















Blood 
















RBC 
















WBC 
















Eplth. 
















Cttte 
















Bacteria 
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PULMONARY DATA 



USDS"' 1 "* 



for Organ Sharing 



OIS ID: 00020 1995/01/23-1 1 30331 



UNO6I0: 



Donor Name: Mary Doe 



FIRST CXR 

Date: Tim*: 
Interpretation/Comments: 

Change from previous CXR: 

BBBfiMQ CXR 

Date: Time: 
IntM pfvtstton/Cofnfnonts : 



CXR: 



THIRD CXR 

Date: Time: 
mterpretstkm/Comments : 

Chenge from previous CXR: 
FOURTH CXR 

Dste: Time: 
mterpreUiton/Comments: 

Change from previous CXR: 

fifth cxr 

0»ts: Time: 
Interpretation/Comments : 

Change from previous CXR: 

BRONCHOSCOPY 
Date: Time: 
Consulting Physician: 
Interpretation: 

PULMONAR Y COMMENTS 
Com menu: 



CHEST MCABURFMFqffi 



RIGHT LUNG LEFT LUNG 




Aortic Knob 
Width |AW] 



Diophraai 
[Width (DWJ 



Vertical 
Height (VH) 

RCPA 



LCPA 



Measuring Unit: 

1. Length of Right Lung 

2. Length of Left Lung 

3. Aortic Knob Width 

4. Oiephregm WWth 

5. Cheat CUc ^Landmark 

6. Diet. RCPA to LCPA 

7. Tote! Lung Capacity 
a. Vital Capacity 



Males 


pCHTI &I6S 


UC « (0.094 x Ht. CM)-(0.015 x Age in 


TLC - (0.079 x Ht. CM)-(0.008 x Age in 


Yrs.)-9.167 


Yrs.)-7.49 


VC = (0.064 x Ht. CM)-(0.031 x Age in 


VC - (0.052 x Ht. CMM0.018 x Age in 


Yrs.)-5.335 


Yrs.)-4.36 




[1 inch m 2.54 cms] 



Document Infomatlon 

Dete/TlRMCompoeed: 01/23/95 02:51:03 PM 
Original Document Author: Audrey NeHsen/UNOS 
Author Acceee: OIS Organ Center; Audrey Neiben/UNOS 
Riader Aooeaa: Audrey NeilserVUNOS; UNOS 



MICROBIOLOGY 



"for Organ Sharing 



OiS ID: 00020- 199M) 1/23-1 1 XX3 31 



UNOSIO: 



Donor Nam*: Mary Doe 



Culture 


Da* 


24hr Result 


Date 


40hr RmuH 


De* 


Final Result 


Blood 














Mood 














UHn* 














Sputum OM ST 














8putum 














CSF 














R. Ur+tf 














L Ureter 














Kidney Baatn 
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PANCREAS DATA 



I k l/^C United Network 
KJ N V^/Ofor Organ Sharing 



OI8 10: 00020- 1995rf)t/23-1 1 03:31 



UNOSID: 



Donor Name: Mary Doe 



Not Raoovarad 



Aortic Flush Start Time: 
Solution: 

8plenic (In pan) Rush Start Tlmi: 



Fluah CharactartaHc: 



8otutk>n: 




Voiuma: 


Fluah Characteristic: 


8JIJL (in pan) Fluah Stan Tlma: 
8olutk>n: 


Voluma: 


Fluah Charectertatlc: 


Whole: Calac 




8plaan Attachad: 


Portal Vain: 


Anatomical Abnormality 




Commenta: 


Surgical Damaga 




Com man ta: 



Recovering Surgeon: 
Date Racovarad: 



Transplant Program: 
Tlma Racovarad: 
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ARTERIAL BLOOD GASES 



LNOS; 



United Network 
for Organ Sharing 



OIS ID: 0002* 1B9S01/23-1 1 03:31 



UNOSID: 



Donor Nam •: Mary Doe 





1. Admit 


2. 




4. 


5. 


e. 


7. 


Da It 
















TTroa 
















PM 
















pco, 
















po. 
















MCO, 
















0,Set 
















FIO, 
















Rate 
















TV 
















PEEP 
















PIP 



















8. 


0. 


10. 


11. 


12. 


13. 


14. 


Date 
















tkiM 
















PH 
















pCO, 
















po, 
















MCO, 
















op* 
















no. 
















Rata 
















TV 
















PEEP 
















PiP 
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CARDIAC DATA 



INOSSSSr""* 



Sharing 



OIS 10: 0002CM095/01/23-1 1 03:31 



UNO6I0: 



Donor Ham*: Mary Doe 



EKO 
Date: 

fcvtftfpfetatlofi: 
DeU: 

Interpretation: 

CVP: 
Pteeeore: 



TVna: 



Tlme: 



BP:/ 



Consulting Physician: 

Oomuttng Physician: 

MR: Htart Rhythm: 



Drug Nam* 


Drug Dosaga 























ANGtOQflfPHY 
DaU; 

Interpretation: 



Tune: 



Consulting Physician: 
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cbc & Din 



L^JOS? i,c ' ,Ne ' , ™ ,l 



for Organ Sharing 



«S ID: 00020-1995/01/2^1 1 X)3:31 



UNOS 10: 



Donor Nam*: Mary Doe 



CBC A Dfff 

^*w^%* V Will 


1. Admit 


2. 


3. 


4. 


5. 


e. 


7. 


Oslt 
































RBC 
















WBC 
















H.b 
































































Lymphs 
















Mands 
















Mono* 
















Eos 

















































CBC t om 


e. 


9. 


10. 


11. 


12. 


13. 


14. 


Ds* 
















Time 
















RBC 
















WBC 
















H.b 
















mm 
































Bege 
















Lymphs 
















Msnde 
















Monoe 
















Eds 
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CHEMISTRY 



I k |/^\C United Network 
LJNV^Ofor Organ Sharing 



as ID: 00020- 199M) 1/23- 11 303:31 



UNOGID: 



Donor Nimt: Mary Doe 



Ufa Data 


1. Admit 


Z 


3. 


4. 


5. 


6. 


7, 


Date 
































Ma* 
















































CO 
















BUN 
















craatinina 
































V-aiCIUm 
















P#l WlA/Ml Hit 

niovpnonn 
















fU limb In 

04 III UU 111 
















SGOT/AST 
















8GPT/ALT 
















GOT 
















Alb/Tot Pro 
















Mg/Choteit 
















AJkPhoa 
















L0H 
















PT 
















PTT 
















Amyiaa* 
















Upaaa 
















Oaatfn* 
CUaianoa 

















Lab Data 


6. 


9. 


10. 


11. 


12. 


13. 


14. 


Date 
















Tfcna 
















H»+ 
















K« 
















O 
















co t 
















BUN 
















OMtlflifM 
















Olucoa< 








\ 








Calcium 
















Phoaphorua 
















Bilirubin 
















8GOT/AST 
















8GPT/ALT 




■- 












GGT 
















Alb/Tot Pro 
















Mg/Chotost 
















AlkPhoa 
















LOH 
















PT 
















PTT 
















Amytaaa 
















L^aM 
















CraatJna 
Oaaranca 
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HEMODYNAMICS/TEMPERATURE 



I k |/^NQ United Network 
\J Nv_/3*or Organ Snaring 



CMS ID: 00020 199^01/23-11 t>3:31 



UNOS ID: 



Donor Nam*: Mary Doe 



1. Admit 



Date 



TlmaRanga 
Avwiq* B/P 



Haart Rait 



High B/P 



Low B/P 



Duration 



CVP 



PA 



PAWP 



CO/CI 



Tamp 



tnotropaa/ 
vaaopfaaaora 



Do«ag« 





a. 


o 


10. 


11. 


12. 


13. 


14. 


Date 
















Tlmt Rang* 
















A wrap* B/P 
















Htart Rate 
















High B/P 
































Low B/P 
















Duration 
















CVP 
















PA 
















PAWP 
















CO/CI 
















Tamp 
















Inotropea/ 
vaeopraaaora 
















Doaaga 
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INTAKE/OUTPUT 



| k United Network 

VJ N V_-Ofc>r Organ Sharing 



as ID: 00020- 199SD1/23-1 1 *)3:31 



UNOSID: 



Donor Nam*: Mary Doe 



MTAKE 



1. Admit 



5. 



DM* 



Crystalloid 
Amount 



Colloid 
Amount 



Total Blood 
Products 



OUTPUT 





24 Hr Urina 

Output/ 
HrAvg 


















Othsr Amt: 

Non-Urlna 

Output 


















24 Hr Total 
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What is Placement? 

Placement refers to the process of adding donors to the national transplant data system, running the 
donor/recipient matching list, and placing a donated organ(s) with a computer-matched waiting transplant 
candidate. For example, a member of the procurement team from an Organ Procurement Organization 
(OPO) enters information into UNet 3 " about the donor, such as blood type, age, size, and condition at 
time of death. Once the information is entered, the procurement team member "runs a match" to obtain a 
waiting list of potential transplant candidates. 

From this point, the organ(s) may be allocated to specific transplant candidates in rank order of the match 
list. Since these functions are primarily the responsibility of OPOs and histocompatibility laboratories, 
staff members of these organizations are the primary users of the Placement section. 
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How Placement Works 

UNet 5 " contains a Placement section that allows its users to enter and maintain donor data and run 
donor/recipient matches. The following functions included in the Placement section: 

• Adding a local donor 

• Searching for a previously entered donor 

• Running organ specific matches 

• Recording organ offer information ("PTR") 

• Accessing import donor information 

• Running matches on living donors 

• Adding and running matches for test donors 

• Maintaining your OPO's list of donor hospitals 

• Entering Crossmatch results 

• Recording donor feedback 

• Referencing current payback status 

• Viewing Completed and Expected PTR data 

• Importing PTR data 

• Entering monthly referral data 
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Screen Elements 



Menus 

The Placement section uses a split screen to help you quickly access the information you wish to view. 
Top Menu Bar 

The top menu bar displays the UNOS UNet*" sections. Click on the Placement button to navigate 
through the different sections. The section you have chosen will appear with a white background The 
top menu bar also provides access to the Help (question mark), Access (key) and Contact (envelope) 
features in UNet. 



Left Menu 

The left side of the split screen displays the topics available in the Placement section. 
Donors 

X Hatch Results 
Feedback 
Payback 
PTR 

Referral Data 

When you click on the Donors button, a submenu of topics displays to the left of the split screen. 



Donor Hospitals 
Living Donors 
Test Donors 

X Match Results 
Feedback 
Payback 
PTR 

Referral Data 




Placement 
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Right Window 

When you first open Placement, the right window of your screen displays general information about the 
Placement section. 



Page: 432 Group Cd: UAOB Oata C4i UAOB 
4370 • John Smith lnckp*ndeni OP0 



Placement updated: 11.05.2001 

If you need help using the Placement section, 
please refer to the Placement Online Tutorial. 

Match Run Export Enhancements 

Several enhancements have been made to the match run export process. Match runs for all organ types 
may now be exported. The screen for exporting match results has been modified to accommodate 
exporting either full match results or only PTR offer fields. The PTR offers file is exported In tab- 
delimited format and is smaller than the full match results file. It includes ail the fields necessary for 
obtaining or entering PTR data. The full match results export file is defaulted to the fixed-width file 
format However, we have added a checkbox on the export screen to allow you to choose the file in tab- 
delimited format We have also added the ctrj>x_id (Center's Patient ID) to the end of all the export 
files. (This field, if completed., is a transplant center-specific ID number.) The length of the PTR offers 
file or the full match results file may be chosen by indicating the ending classification on the match, or 
by selecting an ending sequence number. 



After you have made your selection from the left menu, the right window displays your working area. This 
includes forms, reports, and any other requested information. In this example, the Crossmatch Results 
Search screen is displayed after clicking the XMatch Results button on the left menu. 



Donor* 

X Motch KfeJMJtts. 


Crossmatch Results Search 




Search Criteria 


FmAocIc 






Date Entered; Between And 


P*yb*ck 


1 1 


PTR 


Donor ID \ j 


Referral D<ta 








Note: When moving through menus and forms, be sure to use only the application buttons within 



UNet Do not use the internet browser buttons. 

For additional information about menus in UNet, see the Menus topic in the help file for each 
section (General, Waitlist and/or Tiedi). 
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Form and List Buttons 



The Placement section display several buttons to move you through data completion, or to display a 
listing of valid choices. Notice that your cursor changes to a hand when it is over a UNet SM button. 



Menu Buttons 

Menu buttons allow access to functions pertaining to each topic listed. Click the appropriate button to 
execute the following tasks: 



Donors 



Display a submenu for local donors, import donors, living donors, test 
donors and donor hospitals. The Local Cadaver Donor Search Page 
displays by default. 



Looal Donos 



Import Donors 



Display a screen to search for or add cadaveric donors 

Display a screen to view imported cadaveric donors and run matches 



Donor Hospitals 



Display list of, listing an OPO's Donor Hospitals, and provide add and 
edit functionality of the Donor Hospitals 



Living Donors 



Display a screen to search for living donors to whom an OPO has been 
given access to run a match. 



Test Donors 



Display a screen to add test donors and run test matches. 



X Match Results 



Feedback 



Payback 



PTR 



Expected PTR Data | 



Display a screen for adding, editing and accessing crossmatch results 
Display a screen for accessing and editing open donor feedback 



Display the Payback Accounting Search screen for viewing payback 
debts and credits 

Display a submenu for expected PTR data and importing PTR. 



Display a screen for accessing and editing expected and overdue PTR 
data. 



PTR Offer Import 



Display a screen for importing PTR Offer data. 
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Referral Data 



Display a screen for entering donor hospital-specific data on donor 
referrals 



Action Buttons 

Action buttons allow movement to a different display or form, and/or perform the requested action. Click 
the appropriate button to execute the following tasks: 



Request that a new donor hospital be added to UNet 



ykSfetaS^ Display information about a potential transplant recipient 
Close a match run 



|rw^^| Found on the Donor Hospitals list, to delete a hospital from an OPO's 
jj st aisq f 0unc j on the Crossmatch Results screen for deleting a 
crossmatch record. 



deleting \ 

Export a match run to a text file 

Find a specific candidate in the potential recipient list 

Go to a specific sequence number in the potential recipient list 

; Give access to another OPO to view a donor and run a match 

| Request a new donor match run 



!^&ffJ5£& View the next potential recipient without saving the current record 



f^f^fr^^i Print the Match Results Report 

) Restore page periodically until match is complete 
Save donor information and run match 



View the potential recipient score for organ matches that use allocation 
points 



*^SSS!9 Save ^formation on a potential recipient record 

Save information on the recipient record and go to next offer 



Note: For additional information about form/list buttons in UNet, see the Form/List Buttons topic 
in the help file for each section (General, Waitlist and/or Tiedi). 
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Using the Placement Section 
Placement Access 

Each UNOS Member has a UNet 8 " Security Administrator who is responsible for assigning and 
maintaining security access for each individual user. This process includes: 

• Assuring that each individual user is registered with the UNOS Membership Department. 

• Creating a UNet Security Profile for the individual user, which includes the user's loqon ID 
password and access control. 

• Assigning one or more Security Groups to the user. 

Your UNet display depends upon your Security Profile. Each Security Profile allows access to specific 
parts of the UNet system and limits or restricts the user's access to certain applications. For example if a 
user's responsibilities include adding donors to UNet, his/her access should include access to that oart of 
Placement. 

The UNet menu does not display restricted areas as a choice. In some cases, the user can access an 
application, but certain selections, actions, or information are restricted and not displayed. 
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Beginning a Session in Placement 

1 . From any screen in UNet^, click on the Placement button located on the top menu bar as 
displayed below. The main screen will display the left menu and right window. The Data Cd 
displayed at the top-right of the screen is the center with which you are currently logged in. It 
defaults to the last institution you accessed in this section. 



Placement 



Placement 



Match Run Export enhancement* 



P*f«t 422 (n« Cat MOB Data Mi MOB 



Updated: 11.05.2001 

If you ft»*d h#ip uiing th« Pl»cam#r* *«<*ior\, 
pl««f • r«f«r to th« H»coro*r>i Ctnl*** Tut»n;>t. 



Sav*r»f «nh»r>c«fn*Ats hav* bft«n m»d* to th# m*t«h run t*port proctff M»t«h run* for ill org«n typ«« 
m*y rvov b» «xport*d. Th* ier#«n for exporting match racufti K*i b**n modtfiad to •<xommod*t* 
«xDo»t»n9 «»th«r M rn*tch r«iuhs or only PTR off »r f*«ld* Th» PTR off*rT Ma if «*port»d m t*b> 
dtlimiUd format «nd ii 4rniH«r th«n tht fvli m#uh itjulti ftte. It iftdyda,! til tht folds n«t*<i «ry for 
obt»ining, or »nUr»ng PTft, d>U. Th« full miitfi wute oxport ftU it d«fWtad to th« fix«d-»ldth ftU 



If you would like to change the institution, dick the Access button on the top menu bar. Then 
select the desired institution/program from the drop-down menu and click the Go button. 



institution Access 



Select en Institution: 
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Donor Hospitals 

Accessing the Donor Hospital List 

When adding a donor to UNet 5 ", the donor hospital is a required field. A list of donor hospitals 
associated with your OPO is available in the Donor Hospitals section. 

1 . Begin your Placement session. (See Beginning a Session in Placement) 



2. From the Placem ent menu page, click on the 



Donors 



Donor Hospitals 



button on the left menu. Then click the 



button. The Donor Hospitals list is displayed for your OPO. 



Donor Hospitals for MAOB 



Provider 




City 


State 


Statu* 




AAA &AYSTATE MED CENTER 


SPRINGFIELD 


MA 


Active 


220128 


ADDISON GILBERT HOSP 


GLOUCESTER 


MA 


Inactive 


2*Dft30 


AMERICAN RED CROSS BLOOD SVCS 


DEDHAM 


MA 


Inactive 


01G14i 


AMI WEST ALABAMA GENERAL HOSP 


NORTHPORT 


AL 


Active 


220C29 


ANA JACQUES HOSP 


NEWBURYPORT 


MA 


Active 



Note: You may resort your fist by clicking on any column designated with a red drop- 
down arrow. The hospital may be re-sorted by provider number and name. 

3. To access information about a hospital listed, click the hospital's Provider #. The Donor Hosoital 
information page will display. H 



Donor Hospital 
Hospital Information 

OPO: 22P001 - MAOB - Nev England Organ Bank 
Donor Hospital : 22007? - BAYSTATE MED CENTER 

(AAA BAYS TATE MED CENTER " 
Time Zone? 



Longitude: 
Statu* : 



(EASTERN _J 
72.6085 degree* West 



Latitude: 42.1213 degree* North 



Active 



Inactive 



4. You may modify the name of a donor hospital and/or change the time zone information. 

5. Cii ck the Update button to save any changes, or click the Back button to return to the Donor 
Hospitals list. 
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Adding/Deleting a Donor Hospital 

1 . Access the Donor Hospital list. (See Accessing the Donor Hospital List) 

2. Click on the ty§™P button at the top of the page. The Provider Search screen is displayed. 



Provider Search 






Search Criteria 






Humbert 


I 

I 




Nam*: 




City t 


I 




SUtft; 


I 











3. Enter your search criteria and click Continue. For steps on adding a new donor hospital to 
UNet 5 * 4 , see Adding a New Provider to UNet 

The Donor Hospitals page is displayed with results from the search. 



Donor Hospitals 
Search Criteria: 

Prov Start* ■ A2 








Results from search. If needed, choose a hospital to add. 








032542 -ARCADIA DIALYSIS CTR PHOENIX. A2 

03028E - ARIZONA STATE ELKS ASSN HOSP. TUCSON. AZ 

03029E • BAGDAD HOSP. BAGDAD. A2 

0300S3 - BAPTIST MEDICAL CTRSCOTTSDALE. SCOTTSDALE, AZ 


=i 




Currently assigned hospitals, if needed, choose a hospital to delete. 






220)77 - AAA BAYS TATE MED CENTER 
2201 28 - ADDISON GILBERT HOSP 
22D830 - AMERICAN RED CROSS BLOOD SVCS 
010145 -AMI WEST ALABAMA GENERAL HOSP 


zl 












3 [fr&^m'-ij E£fey«aB7rf 


i Baa 



From this page you may: 

• Select a hospital to add from the search results (at the top of the page). Click the Add button 
at the bottom of the page. The following message is displayed: 



i — — — — . 

| Successfully added do nor hospital record. 

• Select a hospital to delete from the list currently assigned to your center at the bottom of the 
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page (the bottom area on the page). Click the Delete button. The following message is 
displayed: 



| Successfully deleted donor hospital record. 



| 

! 

j 

J 
j 

! 
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Adding a New Provider to UNet 5M 

If a donor hospital is not listed in UNet 8 ". you may request that it be added. 

1 . Access the Donor Hospital list. (See Accessing the Donor Hospital List) 



Provider Search 

Search Criteria 

Number: | 
Name : | 

state. | T] 



3. Enter the provider number only and click Continue. The following Donor Hospitals screen will 
display: 



Donor Hospitals 

Search Criteria: 
Prow Hum « 121212 



No provider* returned. 

Add Now Provider - This is to add Non-UNOS members ONLY. 

Thij is to be used when searching only by entire provider number. Mew UNOS requests for TXCs, labs ; 
and OPOs are to be handled through UNOS Membership Department. 



Currently assigned hospitals. If needed, choose a hospital to delete. 



2. 



Click the 



button at the top of the page. The Provider Search screen is displayed. 
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4. Click the Add New button. You will be asked to confirm that the provider number is correct 
before continuing, because you will not be able to change that number on the following page. 
More than one hospital can be listed with the same provider number. The Request to Add New 
Provider page will display. 



Request to Add New Provider 

This is to add Non-UNOS members ONLY. 

New UNOS requests for TXCs, Labs, end OPOf ere to be handled through 
UNOS membership department. 



Use the form below to send your request for a new provider to be added. 
Requestor Information 

Name: John Smith 

Institution: MAOft - OPl 




E-mail! 



5. 



After completing the form, click the ^ 
UNOS Help Desk to be processed. 




button, and your request will be forwarded to the 



Note: This request form is to add Non-UNOS members only. Contact the UNOS 
Membership Department to have UNOS transplant centers, iabs or OPOs added. 
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Inactivating a Donor Hospital 

A donor hospital that is associated with one or more donors in UNet SM cannot be deleted from the list. 
However, you may inactivate the donor hospital if it is no longer used, so that the name will no longer 
appear on future Donor Referral lists or as a choice when adding a donor. 

1 . Access the Donor Hospital list. (See Accessing the Donor Hospital List) 

2. Click the Provider # of the center you wish to inactivate. 



Provider 




City 


State 


Status 




AAA BAYSTATE MED CENTER 


SPRINGFIELD 


MA 


Active 




ADDISON GILBERT HOSP 


GLOUCESTER 


MA 


!n»ctiv* 



The Donor Hospital Information page is displayed. 



Donor Hospital 




Hospital Information 




OPO: 22P001 - MAOB - New England Organ Bank 




Donor Hospital; 220077 - BAYSTATE MED CENTER 




(AM BAYSTATE MED CENTER 




TimeZonet {EASTERN _J 




Longitude: 72.6085 degrees Weft 


Latitude: 42.1213 degrees North 


Status: A /■* , 

1# Active * Inactive 









3. Click on the Inactive button at the bottom of the page. 

4. Click on the Update button to save the change. When you return to the Donor Hospital list page, 
note that the Status column on the right side now displays Inactive for this hospital. Inactive 
hospitals will not display on future Donor Hospital Referral Data lists or as a choice in the Donor 
Hospital drop-down box on the donor entry page. 



Donor Hospitals for MAOB 






Successfully updated donor hospital record. 










wmm 


Provider #▼ Name" 


City 


State Status 


AAA BAYSTATE MED CENTER 


SPRINGFIELD 


MA Inective 
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Donors 



Accessing an Existing Local Donor 

1 . Begin your Placement session. (See Beginning a Session in Placement) 



2. Click on the 



Donors 



button on the left menu. The Local Cadaver Donor Search page is 



displayed. Any donors added within the last 5 days will also display on the page, to assist in 
preventing duplicate donor entry. 



Local Cadaver Donor Search 
Search Criteria 



Add Date: 

Donor Id: 
Donor Hoipit*t: 
List Name: 
Age Range: 

ABO: 



Between 



end 



Between 



r^3 



end 



\3 



I 1! 



Donors added within the last 5 days 



Donor ID 

OJM001 



R obi ns on, Test 



*9* 

33 yrs 



Female 



A8P 
A 



If the donor appears at the bottom of the screen, click on the Donor ID to display the donor 
record. Otherwise, enter any combination of search criteria and click on the Search button at the 
bottom of the page. The Local Cadaver Donors list is displayed. 



Local Cadaver Donors 


















■eliSBimi 


Donor ID . 


Age 


Gender 


ABO 


Add Date 


OJMOGJ Robinson, Test 


35 yrs 


Female 


A 


10/13/2001 11:04 


Vader, Darth 


70 yr5 


Male 


A 


06/23/2001 00J47 
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4. Select a Local Donor from the list and click on the Donor ID. The Local Cadaver Donor page is 
displayed for the donor you selected. 



Local Cadaver Donor 



UNOS ID Information for Donor ID: O3M00I 

OPO: 22P0Q1 - MAOB * New England Organ Bank 
Donor Hospital* 220029 - ANA JACQUES HOSP 
Donor Name: Robinson/ Test 
Donor f-eedback: Statu* OPEN 



Match Run Information 

ABO J A 

Age: 35 Yaars 

DOB: 05/19/2001 



Gender: Female 

Height! 5 ft 0 in/132.4 cm 

Weight: 123 lbs/S6.$99 kg 



Viewing and Editing Donor Information 

a To edit the donor information, click the Edit button at the top of the page. Enter or change 
information and then click on the Update button at the top or bottom of the page. 

a To display existing match results for the donor, use the scroll bar on the right side of the 
screen to navigate to the bottom of the page. Click an organ noted as complete in the list of 
Match Runs. The match list will display on the screen. 

a To view or complete Donor Feedback, click on Donor Feedback, which appears beneath the 
donor name at the top of the form. The Donor Feedback status is noted on the form as either 
OPEN or CLOSED, 
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Adding a Local Donor 

1. Begin your Placement session. (See Beginning a Session in Placement) 



2. Click on the 



Donor? 



button on the left menu. The Local Cadaver Donor Search page is 
displayed. Any donors added within the last 5 days will also display on the page, to assist in 
preventing duplicate donor entry. 



Local Cadaver Donor Search 
Search Criteria 

Add Date: Between 



and 



Donor Id: 
Donor Hospital: 
Lart Name: 
Age Range: 

A&O: 



"3 



Between 



and 



Donors added within the last 5 days 



ID 

07*00 J 



Robmson/Teft 



A9« 

35 yry 



Cender 
Female 



ABO 

A 



3. Click on the Add button at the bottom of the page. The Cadaver Donor Add form is displayed. 



Cadaver Donor Add 








UNOS ID Information 




OPO * 22P001 - MAOB - New England Organ 


»anl< 


Donor Htxprtaf * 






J 


Last Name* 


First N*rr>« 


I 

Ethnicity: * 

I J 


1 


Race:* 




V white 




r* Black or African American 




V Amencan I ndi aft/Ala* kan N«tiv« 




1 Asian 




r~ Native Hawaiian or Other Pacific liUnd*< 




JT Mid-eest/Arebien 




f~ Indian Sub-continent 
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4. To quickly obtain a donor ID, complete only the required fields of Donor Hospital. Name, Ethnicity 
and Race. If you have additional donor information, proceed with completing the applicable 
fields. 

5. Click on the Save button at the top or bottom of the page. 

Note: You may save the record and run a match simultaneously by clicking on the Run 
Match button. See Running a Match for steps on running a match and placing organs. 

6. The Local Cadaver Donor Search page reappears. A message is displayed that the donor record 
has been successfully added, along with the donor name and the donor ID. 



Local Cadaver Donor Search 

Successfully added donor Robinson, TestDonor IP: OJMOQ1 
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Accessing Imported Donors 

When an OPO needs to run a match for a donor organ that was originally recovered by another OPO, the 
receiving OPO must first be given access to the donor by the originating OPO. 

To access the imported donor record: 

1 . Begin your Placement session. (See Beginning a Session in Placement) 

button on the left menu. Then the I import Donor?"} bution JmpQft 
Cadaver Donor Search screen is displayed. 

Import Cadaver Dcnor Search 

Donor Id: I 



3. Enter the Donor ID and click on the Search button. 



2. Click on the 



Donor's 



4, The Cadaver Donor Page fs displayed for the donor you specified. From the donor record, you 
may run a match and place the organ as described in the lesson for Running a Match. The 
match run is only accessible to the OPO who runs it. 

Note: if you are unabie to access the import donor record, contact the originating OPO to 
verify that import Access has been given. (See Giving Import Access to Another OPO for more 
information) 
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Accessing a Living Donor 

In cases of anonymous living donor transplants, the work-up transplant center must designate in Tiedi® on 
the living donor record that the OPO can run a match on that donor. 

Once the transplant center has given access, you may open the living donor record by taking the 
following steps: 

1 . Begin your Placement session. (See Beginning a Session in Piacement) 



2. Click on the 



Donors 



button on the left menu. Then click the 



Living Donor? 



button. The 



Living Donor Search page is displayed. 



Living Donor Search 

Donor Id: Jj 



3. Enter the Donor ID and click on the Search button. 

4. The Living Donor record will display for the donor you specified. You may run a match and place 
the organ as described in the Running a Match lesson. 
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Adding a Test Donor 

The Test Donor function is available for OPOs to use in training their staff, and may also be used to 
locate where local transplant candidates would appear on a match list, given a set of test data. 

To add a test donor: 

1 . Begin your Placement session. (See Beginning a Session in Placement) 



2. Click on the 



Pernors 



button on the left menu. Then click the iTestPonos I button. The Test 



Cadaver Donor Search page is displayed. 



Test Cadaver Donor Search 
Search Criteria 

Add Date; 



Between 



and 



Donor Id: 
Donor Hospital; 
Lest Name: 
Age Range; 

A60: 



Between 



and 



"3 



I 3 



4. Click on the Add button. The Test Cadaver Donor Add page will display. 



Test Cadaver Donor Add 



UNOS ID Information 



mmmm&mmmmmMmm 



OPO » 22P001 - MAOB - New England Organ Bank 
Donor Hospital* 



Last Name* 



First Name 



r 

Ethnicity; R 



I 3 

Race:* 
r White 

r* Black or African American 
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5. Complete all the required fields (Donor Hospital, Name, Ethnicity and Race) and any optional 
information. 

Note: Weight and height are not required for test donors. 

6. Click on the Save button. You may save the record and run a match simultaneously by clicking 
on the Run Match button. 

7. The Test Donor Search page will reappear, with a message that the donor record has been 
successfully added, along with the donor ID: 



Successfully added donor Smith, JohanDonor ID: 200059 
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Running a Test Match 

The Test Donor function Is available for OPOs to use in training their staff, and may also be used to 
locate where local transplant candidates would appear on a match list, given a set of test data. 

To access a test donor and run a match: 

1 . Begin your Placement session. (See Beginning a Session in Placement) 



2. Click on the 



Don one 



Test Cadaver Search page is displayed. 



button on the left menu. Then click on the I Test Donors'] b utton j he 



Test Cadaver Donor Search 
Search Criteria 

Add Data: feetvetn 



and 



Donor Id: 
Donor Hospital: 
Last Nam*: 
Ao,a Range: 

ABO: 



Betw»«n 



and 



I 3 



3. Enter your search criteria and click on the Search button. A list of test donors meeting your 
criteria will display. 



Test Cadaver Donors 


















Ml 


Donor ID N»m« 
20002; Attst really 


Age 

30 V'* 


Gender 
Ftmait 


ABO Add Date 

A 07/20/2001 14:26 
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4. Click on the Donor ID to display the Test Local Cadaver Donor page. 



Test Local Cadaver Donor 



UNOS ID Information for Donor ID: 200022 

OPO: 22P001 - MAOB - New gnoJend Organ Bank 
Donor Hospital: 220029 - ANA JACQUES HOSP 
Donor Name: A test, really 



Match Run Information 

ABO: A 

Age; 30 Years 

DOS: OX/01/1971 



Additional Match Run Information 



Gender: Female 

Height! 3 ft 5 in/l&3.1 cm 

Weight; 155 lbf/70.3068 kg 



HCV Antibody: Negative 

Hepatitis & Core Antibody! Negative 

HLA: AtlO Ai3 Bil2 &:12 DR:6 DR:7 

Previous Gastrointestinal Disa^s^: Ho 



5. Click on the New Match button to enter test match run information. 



hatch Run* Requested 








H Kidney 


r 


Heart 


r Liver 


P Kidney/Pancreas 


r 


HearVtune, 


!"* intestine 


P Pancreas 


r 


Lung 





6. Select the or gan-specific ma tch runs requested, as well as any additional match run information. 
Cfick on the ils^^^S button. 



Note: Height and weight are not required to run a fesf match. 

7. The Match Run page will refresh with the box at the top noting the matches as Organ Type 
(Queued) or Organ Type (Running). 



8. Click on the ¥^^^ button at the top or bottom of the page periodically until the match has 
completed. 

9. Click on Organ Type (Completed) to view the Potential Recipient List. 

10. When reviewing a test match, note that candidates from outside of your OPO are blinded by the 
system. Their information will appear as asterisks. This blinding provides patient and center 
confidentiality. 

Note: To view the Potential Recipient List at a later date, access the Test Donor as before, and 
select the applicable Match Run at the bottom of the Test Local Cadaver Donor page. 
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Match Runs 
Running a Match 

1 . Begin your Placement session. (See Beginning a Session in Placement) 

2. Access a donor record as explained in Accessing an Existing Local Donor (The steps for 
running a match are the same for local, import, living and test donors). 



3. Click on the 

4. Review and edit any information. 



button at the top or bottom of the page. 



The organ specific match choices are found in the Match Runs Requested section. Check the 
type of match needed. 



Natch Runs Requested 








r Kidney 


r 


Heart 


n uvei 


r Kidney/ Pancreas 


r 


Heart/ Lung 


F" Intestine 


f" Pancreas 


r 


Lung 





Note: For entered Crossmatch results to be considered in the kidney or kidney/pancreas 
match process, you must designate the tray or trays to be included. This can be done by 
choosing a tray or trays from the field labeled Select Crossmatch results in the middle of 
the page. Multiple trays may be chosen by holding down the Ctrl key on the keyboard 
while using the mouse to highlight the trays to be considered. 



It there time for * 
Preliminary Crossmatch? 
Select Crof smatch results: 



6. Click on the 



button at the top or bottom of the Cadaver Donor page. 



7. The Match Run page will refresh with the box at the top noting the matches as Organ Type 
(Queued) or Organ Type (Running). 



8. Click on the 1 
completed. 



1 button at the top or bottom of the page periodically until the match has 



9. Click on the Organ Type (Completed) to view the Potential Recipient List. 

Note: To view the Potential Recipient List of a match that has been previously run, access 
the Local Donor as before, and select the applicable Match Run at the bottom of the Local 
Cadaver Donor page. 
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10. The Potential Recipient List will display 20 records per page. Each candidate on the list is 
identified by match sequence number, center code, SSN, name and a contact phone number. 



Seq# Hosp 


SSN Nam* 


Contact* 


Refusal Organ 








Coda Accepted 


13911 ALUA-TX1 


Attest, Bob 


(800)232-3677 





On a Pancreas Match Run, if the 4-letter Center Code has parentheses around it, that center will 
accept a facilitated pancreas. Click on the SSN to view information about the potential recipient 
and record organ offer data. 



12934 (ALUU-TX1) 111-22-3333 Doe, Jane (800)252-9000 

11. To view the next 20 records, click on the arrow button at the bottom of the page. 

m O §3. EH 

Beginning of List Previous 20 Next 20 End of 

Records Records List 
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Finding a Specific Candidate on the Match Run 

To find a specific candidate on the match run, or to find a candidate who was screened off the list, take 
the following steps: 

1 . Access a match run. (See Running a Match) 

2. Click on the button at the top of the page. 



Find a Kidney Candidate 








Search Criteria 










Tx Center: * 


I 




-J 




Candidat* SSN: 


I 








Last Name: 


I ' 








First Names 


I 








Records Per Page! 


no 








Indude: 


Located on Match 


r 


Screened off Match 


C Both 


Sort Order: 


Seq# 


r 


Name 


*~ Reason 










\wmmwamm 







3. Enter a transplant center and any other search criteria. 

*Vofe: You will only have access to centers that are affiliated with your OPO. 

4. Click on the Continue button. The Find a Candidate Search Results page will display. 



Find a Candidate Search Result? 












Hatch Information 






Donor ID* OMOOl 


Donor Name: Robinson, Test 




Match Run: 1 


Match ID: 98027 




Name SSN 


Seq # Reason Statue 


Origan 



5. Search results will include either a sequence number of the potential recipient on the list, or the 
reason code for why the potential recipient was screened off the list, dependent on the criteria 
entered. 

6. By clicking on a candidate's Reason code, you may display a snapshot of their record at the time 
of the match run. 

Note: The I ^o^^ ] button at the bottom-right of the search results screen provides a list 
of the reason codes. 
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Going to a Specific Sequence Number on the Match Run 

To go directly to a specific sequence number on a match run, take the following steps: 

1 . Access a match run. (See Running a Match) 

2. Click in the Go to Candidate Sequence Number field, and type the sequence number you wish 
to view of the candidate. 



Go to Candidate Sequence Numbe 



r 5 {TT 



3. Click the Go To button. The Potential Recipient List will refresh to display the sequence number 
of the candidate you designated. 



$mq* Hoap 


SSN 


Name 


Contact # 


Re fatal Organ 










Code Accepted 


15 MABS-TXJ 


111-12-1241 


SMITH WILLIAM 


(800)874-5215 
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Giving Import Access to Another OPO 

When an OPO needs to run a match for a donor organ that was originally recovered by another OPO, the 
originating OPO must first give access to the donor record. 

1 . Access a match run. (See Running a Match) 



2. Click on the ^=^^ = button at the top of the match. A list of all OPOs will display. 



Import Access 












Select the OPO(s) you want to give import access to: 






1""* ALO& - Alabama Organ Center 






f" AROR - Arkansas Rag. Organ Recovery Agency 






r A20& • Donor Network of Arizona 






r* CADN • CA Transplant Donor Network 






f"~ CAGS • Golden State Donor Services 






r CAOP - One Legacy 






V CASD - Ufesharing Community Organ Donation 






f"~ CORS - Donor Ajtiance 






.... . .r- 







3. Check off the OPO(s) who need access to the donor record. 

4. Click on the Update button to save the information and return to the Potential Recipient List. The 
designated OPOs will now be able to access the donor record and run matches. 

5. A message will display that import access has successfully been given. However, the designated 
OPO will not be able to view any matches that have already been run by the originating OPO. 

Note: Import access may be taken away by unchecking the box(es) under import Access. 



29 



11/21/2001 



Placement 



Match Runs 



Viewing Candidate Information 

Additional candidate information is available on patients who are affiliated with the OPO running the 
match. 

1 . Access a match run. (See Running a Match) 

2. Click on a candidate's SSN to view the Potential Recipient Information page. The donor will 
display at the top of the page. Information about the potential recipient is displayed below the 
donor information to assist you in making organ offers to the candidates on the list. 



3. Click on the lJ^g^s&^§J button at the top of the screen. This will display the Potential 
Recipient page, which includes provider, demographic and clinical information. It also includes 
the minimum acceptance criteria and unacceptable antigens for the candidate. 



Potential Kidney Recipient 




Provider Information 




Transplant Cantar; 


220031 - MA&U - Boston Medical Center 


24 Hour Contact Phone Number: 


800-446-6362 



4. Click on the Back button to return to the match results. 
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Viewing Potential Recipient Score Breakdown 

A candidate's score breakdown is available to determine why the candidate is located at a specific 
sequence number on the match. The ability to view the Potential Recipient Score is only available for 
organ matches that use allocation points, e.g. Kidney, Liver, etc. 

1 . Access a match run. (See Running a Match) 

2. Click on a candidate's SSN to view the Potential Recipient Information page. 



3. Click on the 



button at the top of the screen. This will display the Potential 



Recipient Score Breakdown, which includes donor and potential recipient information and the 
point breakdown for the candidate. 



Potential Recipient Score Breakdown 

Donor Information for Donor ID: OGS002 

107X9, 1002 
Match Run #: 3 

Match Submit D*t«; 07/19/2001 13:43:15 

HLA: A: 0 A: 0 B: 0 



Bi 0 



Match ID: 

ABO: O 

DR: 0 



72029 



DR: 0 



4. Click on the 



' button to return to the match results. 
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Entering PTR Information 
Entering Organ Offer (PTR) Data 

1 . Access the match run used to allocate the organ. (See Running a Match) 

2. Click on the SSN to view information about the potential recipient and to record organ offer data. 

3. When a placement attempt has been made, the following information should be entered for every 
candidate who was offered the organ. 

• A value for Accept - Yes, No, or Pending 

• If Yes or No, a Respond Date (in MM/DD/YYYY format) and military Time (in HH:MM 
format). Date is required, but Time is not. 

• If Yes or No, the name of the Recipient Center Contact You must fill in first or last name t 
but both are not required. 

• If the organ was refused, the Primary Refusal Code from the drop-down list 

• If the organ was accepted, the organ type accepted 

Note: If 998 is chosen as the refusal code, you must complete the Specify Other field. 



Placement Attempt 

Accept: 

Yet Ho f* Pending 
Respond Detei | Time: f 






Recipient Center Contact 
Firrt Nemet 


Lest Heme: 




I I 

Refusal Cods 


I 

998 Refurel Code - Specify Other 




.J 









mmm 



4. Click the button at the top or bottom of the page to save the record -OR- click the 

button to save the information and go to the next potential recipient on the 



list. 



mm 



The fe-2£ss> button will return you to the Potential Recipient List without saving the current 
record. 



The ^s^^s^ button takes you to the next potential recipient without saving the current 
record. 

For helpful tips on entering potential recipient information, see Tips for Entering PTR Data. 
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Recording a TXC Refusal 

To record the same refusal reason for ali of a transplant center's candidates: 

1. Open the record of a center's first potential recipient on the list, and complete the required fields 
with the refusal information. (See Entering Organ Offer (PTR) Data and Tips for Entering PTR 
Data) 

2. Click on the TXC Refusal button found toward the bottom of the Potential Recipient Information 
screen. 



UPDATES «H MANM-TX1 Potential Recipients from this point forward vith this refusal 
information. 

Existing data will NOT be overwritten. 



3. A warning message will appear. 



Microsoft Internet Explorer 



si-:: J"' 



*1 



Update** be applied to this potential recipient and aB remaining potential recipients 
at the center (those below this sequence number). 

Do you wish to continue? 

Cfck OK to continue or ckk Cancel to return to the page. 



OK 



1 



Cancel 



J 



4. Click OK to continue with the update. The current patient record and all subsequent patient 
records for the same transplant center will be updated with the same refusal information. 

5. A message will display that the TXC Refusal was successful. 



Kidney Donor / Potential Recipient Information 
TXC Refusal Successful 



Note: This action will not overwrite any existing data. If refusal information already exists in a 
record, other than the record you are currently entering, it will not be affected when the TXC 
button is used. If a mistake is made when pressing the TXC Refusal button, the action 
CANNOT be undone. Each entry must be corrected manually. 
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Recording a Range Refusal 

To record the same refusal code for a range of records: 

t. Open the record of a potential recipient on the list, and complete the required fields with the 
refusal information. (See Entering Organ Offer (PTR) Data and Tips for Entering PTR Data.) 

Note: This option can only be used with OPO-specific refusal codes. The accepted codes 
are 906, 991-996 and 998. 

2. Note the sequence number through which you would like to apply the same refusal information. 
Enter this number in the Ending Sequence Number field. This number must be after the current 
record's sequence number, and cannot be greater than the last sequence number on the match. 



UPDATES ell Potential Recipients from this point forward, up to and including the indicated 
ending sequence number regerdles s of center vitn this refuse! information. 
An OPO related refusal code is required. 
Existing data will HOT be overwritten. 

Ending Sequence Number 



3. Click on the Range Refusal button. A warning message will appear. 



Microsoft Internet Explorer 



Update wi be appfied to th*s potential recipient and potential recipients 
through Seq# 4. 

Do you wish to continue? 

CkkOKto continue or rick Cancel to return to the page. 



OK { Cancel | 



4. Click OK to continue. A message will display that the Range Refusal was successful. 



Kidney Donor / Potential Recipient Information 
Range Refusal Successful 



Note: This action will not overwrite any existing data. If refusal information already exists in a 
record, it will not be changed when the Range Refusal button is used. If a mistake is made 
when pressing the Range Refusal button, the action CANNOT be undone. Each entry must be 
corrected manually. 
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Tips for Entering PTR Information 

Entering PTR information can be accomplished quickly with the use of your keyboard. Here are a few 
pointers to help: 

• Begin in the Accept: Yes field in the Placement Attempt section. Simply press the SPACEBAR 
on your keyboard to mark the Yes field. 

• If the answer for Accept is No, press the RIGHT ARROW on your keyboard. Press the right arrow 
once more to enter an answer of Pending. 

• Press the TAB button on your keyboard to advance to the next field. 

• When you reach the Refusal Code field, you have several options. 

• You may type the refusal code, and the closest match will appear. An example is 921 for 
Donor Quality. If a mistake is made, the DELETE key will dear all previous keystrokes. 

• You may also use the up arrow or down arrow to scroll through the list of choices. 

• The HOME key will take you to the top of the list. The END key will take you to the end of the 
list. The PAGE UP and PAGE DOWN keys will skip several choices at a time. 

• To TAB in the reverse order, hold down the SHIFT key as you press TAB. 

• You may use the TAB button to navigate through the remaining buttons/fields on the page (e.g. 
Range Refusal, Update, Next Offer). Press the ENTER key on your keyboard to select the 
button(s) you wish to choose. 
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Exporting PTR Data 



Full match results or PTR offers may be exported for all organ types in a fixed-width or tab-delimited text 
file. The PTR offers file may be opened in a spreadsheet so that data can be entered for the candidates 
on the match. This data can then be imported back into UNet 8 " following the steps in PTR Offer Import. 

1. Access a match run. (See Running a Match) 



2. Click on the 
will display. 



button at the top or bottom of the page. A Match Results Export screen 



Match Results Export 

Hatch Information 

Donor 10 t OJYQfH 
Donor : donor, maob test 

Export Information 

Export type : 



Match 10 : 98200 
Organ ; Pancreas 



Maximum Sequence Numbtr i 412 
Close Sequence Number : 



^ Full Match Results <~ PTR Offers 
Tab delimited H 



Indude results through 
Classification * 



Maximum Se?ueAce Number for Cbssificition *pp**rs in p»r*nth+sis 



Sequer 



Number 



3. Select either Full Match Results or PTR Offers from the Export type field. The PTR offers file is 
exported in tab-delimited format and is smaller than the full match results file. It includes all the 
fields necessary for obtaining or entering PTR data. The full match results export file is defaulted 
to the fixed-width file format, but may be changed to tab-delimited. 

4. The length of the PTR offers file or the full match results file is chosen by indicating the ending 
classification on the match, or by selecting an ending sequence number. 

5. Click the Export button. When the export request is complete, a link similar to the following will 
appear on the bottom of the screen: 



Riflhtdicir and Saw* Target As... to download CnQliOSKm ITJM I.TXT 
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6. Right click on the link and choose Save Target As from the menu. The Save as box appears. 

-2J*I 



Saveirr I £j| Match Exports 



"3 + ©cje 




Fie name: |QJQ005KI01_887 
Save « type: |Tex! Document 



Save 



"3 Cancel [ 



7. Designate the location or directory to which you would like the file saved, and click the Save 
button. 

8. A completed dialog box will display from which you may select Open (to view the file), Open 
Folder (to open the folder containing the file) or Close (to close the dialog box). 



Download complete 



Download Complete 
Saved: CUQ005Kf01_887.txt for Server 

iiiiiiiiiiiiitiiiiiiiiiiiiiiiiiiiiiBninn 

Downloaded: 819bj*esh 1 sec 

Download to: M:\Match ExporU\0JQ005Kiai^887.b<t 

T rarafei fate: 81 9 bytes/Sec 

r Dose dialog box when downtoad cornpletes 

Open | OpenFolde* [| dose | 

9. The corresponding file layouts for PTR Offers and Full Match Results are found in the News 
section of UNet. 
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Printing a Potential Recipient List 

1 . Access a match run. (See Running a Match) 



2. Click on the 



button. The Match Results Report screen will display. 



Match Results Report 
Donor Information 




Donor Robinson, Test 
Metch ID #: 98029 


Donor IDi OJM001 
Organ: Liver 


Report Information 




Choose report type: 

Include report results through: 
j Regional Statu* 1 _J 


Potential Recipient C standard Version 







3. Choose the type of report to be printed, Potential Recipient version or Standard version. The 
Potential Recipient version includes detailed candidate information and space to record organ 
offer information - fewer candidates will print on a page. The Standard version lists candidate 
information only- more candidates will print on a page. 

4. Use the drop-down menu to choose the allocation group (e.g. Common OPO List, Regional List) 
to include as the last section on the printed report. 

5. Click the Print Report button. 

6. The first time you do this, you will be prompted to load an Active Reports Viewer. 



Socurily Wanting 




Do you waritto ms^aifrnjrt*Ac^^ 
signed orv9/1 7/99 10:08^&^ p^fauted b/ 

Publisher outhenfic% verified t^VeiiSign (^mBrbeJ 
Software Publishers GA 

£etriiori: Data Dynamics. UA asserts thotihis content is safe 
You should only insiallAtewthte cohrert.if you trust Date 
: Dynamics. Ud. tomato^ • 



r Ajwoystmstconteitffi™ 



^ I CZ.J^P More Info | 



7. Click Yes to install and run ActiveX. 



38 



11/21/2001 



Placement 

8. A message will display as the report is processing. 



Match Runs 



Your Liver Match Results Report is processing, thank you for waiting. 



9. The Match Results Report will be displayed on the screen in the format requested. 



Liver Match Results Report 



UNOS Lh 

Potentu 
Adult Donor 




Match!* 98029 



OPO: 22P001 - MAOB - New England Organ Bank 

Donor Hospital: 220035 - ATLANT1CARE UNION HOSPITAL 



Demographic Information 



Name; Robinson, Test 



10, Click on the Print icon found at the top of the Active Reports Viewer frame to set your printing 
properties and print the report. 
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ActiveX Toolbar 

IB) | A Prim., I ei<^|TaoF~ 



1/2 



<■ Back 



Zoom Out 

Press the button one or more times to display more of the report on the screen. 
Zoom In 

Press the button one or more times to show areas of the report in greater detail. 
Page Navigation 

Previous Page takes you back one page at a time. 
Next Page takes you forward one page at a time. 

Page Numbers displays the current page followed by the total pages in the report. In the example 
above, the user is on page 1 of a total of 2 pages. The desired page number may also be manually 
entered in this field. 

Hand Cursor 



To see parts of a page not displaying on the screen, click anywhere on the page and drag your mouse in 
any direction. (You may also use the scroll bars at the right and bottom of the screen.) 



Clinical Information 


o 


ABO: A 




Height (cm): 178 


Height (in): 70 


Weight (Kg* 68 v 


KH0W<ms): 150 


HCV Antibody: Negative 





Note the way the hand cursor "grabs" the page as you click and drag your mouse in any direction. 
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Closing a Match Run 

After the last offer has been made on a Potential Recipient List, the Match Run must be closed. By 
closing a match you are indicating that the match is complete as recorded. 

1 . Access a match run. (See Running a Match) 

2. Note the sequence number of the potential recipient for whom the last call was made. 

3. Enter the sequence number of the last call in the field shown below, and click on the Close 
button. 



Sequence Criteria 

tnfr S«qu«nc* Number of th« Urt call to do*« this match run: 



3. A dialog box will display, asking for verification of this action. Click OK to proceed with closing 
the match run. 



Microsoft Internet Explorer 



3> 



WARMING? 

Al entered data after sequence #1 3 w0 be deleted for ths matchrun. 
<3ck OK to continue or cSck Cancel to return to the page. 



OK 



I 



Cancel 



4. A second message will appear, stating that the match run will be closed at the designated 
sequence number. Click OK. 



Microsoft Internet ExplorerS^^^^ 



m 



/ 1\ This "wtch run wd be dosed after sequence *13 

] 



OK 



5. A message will display at the top of the screen that the match run was successfully closed at the 
designated sequence number. 



Match 98029 has been closed at Seq #13. 



If you find that you need to change the match run close number, you may change it to a different 
sequence number. Any records after the close number will be removed. 

Several factors affect how this action can be performed: 

• If any records have a status of Yes AFTER the last call sequence number, a member will not 
be able to close the match run at that number. Those records must be included. 
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• If any records have a status of Pending BEFORE the last call sequence number, a member 
will not be able to close the match run at that number. Those records need to be updated to 
Yes or No. 

• If the Organ Center has entered information in any of the records listed AFTER the last call 
sequence number, a member will not be able to close the match run at that number. Those 
records must be included. 
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Crossmatch Results 
Adding Crossmatch Results 

1 . Begin your Placement session. (See Beginning a Session in Placement) 



2. Glide on the 
will display. 



X Natch Results 



button on the left menu. The Crossmatch Results Search screen 



Crossmatch Results Search 

Search Criteria 

D*t« EnUr«d: B«tw««n And 



Donor ID: 



3. Enter a Donor ID number and click on the Add button. A Select Tray for Crossmatch Result 
page is displayed. 



Select Tray for Crossmatch Result 

For Donor ID: OHV007 

Donor N*mt: expanded a donor ABO: A 



s«l«ctTr»yXOt | N£OB*MJ7/SV2001 -NE08 jj 



4. Choose a tray from the drop-down box to which Crossmatch results will be entered. 
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5. Click on the Continue button. The Crossmatch Results page will appear. The Donor Name. 
Tray Name and ID will be displayed at the top of the page. 



Crossmatch Results 



For Donor ID: oKwO07 

Donor Nam*: «xp*nd«d * donor 
Tray Name: NEO&-O 
Tray ID: 597 



ABO: A 

Tray Data: 07/30/2001 
Lab: NEO& 



SSN Center 


ABO Name 


Row 




Peak 
PR A 


CurrentSarum 

PRA (month/year) 


111-22-3333 MANM 






1A/1 


wz 


80 


50 


01/2001 


100-11-1111 MANM 






IB/2 




85 


40 


01/2001 


456-12-3456 MANM 


A 


Cand<d«t«, Uv*r 


1C/3 








01/2001 


456-12-3456 MANM 


A 


Candidate, Liver 


10/4 








01/2001 


111-22-3233 MANM 






IE/5 
IF/6 


£mpty 


12 


2 


01/2001 



6. Enter the Crossmatch results in the Result fields. Results can be entered either by using a 
mouse to choose the number designated result for each patient, or results can be manually 
entered using the tab key to navigate to the next field. 

7. Once the results have been entered on the tray, click on the Save button. The following status 
message appears at the top of the page; 



Successfully inserted crossmatch record. 



8. To enter results into another tray, repeat steps 4 through 7. 
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Accessing and Editing Crossmatch Results 

1 . Begin your Placement session, (See Beginning a Session in Placement) 



2. Click on the 
will display. 



X Match Results 



button on the left menu. The Crossmatch Results Search screen 



Crossmatch Results Search 

Search Criteria 
Date Entered: Between 



And 



Donor IDt 



3. To search for results that have already been entered or begun, enter the Donor ID number or 
Date Entered into the fields provided, and click on Search. A list will display with the search 
results. 



Crossmatch Results 










ID_ C^coor ID Tray Hmmat 


Tray .Date 


Tray Status 


J>«nw_ Najro 


■gglM 


t*f> 0)3004 NEOB-O 


10/29/2001 


urtc 


Test, Donor 


A 


Page 1 of 1 






Search Criteria: 


f Legend J 








Donor ID « OJ3004 





Note: A search with no criteria entered will display crossmatches added within the last 3 
days. 

4. Click on the tray you wish to view or modify. 



Crossmatch Results 



For Donor 10; oj3004 

Donor Name: Teft, Donor 
Trey Nemet NEOB-O 
Tray IDi 397 
Crossmatch ID; 2$ 6 
Crossmetch Entered By; MAOB 



ABO: A 

Trey Date; 07/30/2001 
Lab: NEOB 

Cronmatch Entered On: 10/29/2001 11:41 



SSN 



Canter ABO Name 



Row 



Remit Peak Current Serum 

PRA PRA (month/year) 



111-22*3333 MA KM B Candidate, Liver 



1A/1 1 



50 



30 



01/2001 
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Note: Click the LEGEND button at the bottom of the screen to see a description of each 
result code. 

5. To modify a tray, click on the Edit button. You may enter or change the Result fields. 



Row 


Result 


1A/1 


foil 


IB/2 




1C/3 




ID/4 





6. Click the 



mmm 



at the top of the page: 



button after entering your changes, and the following message will appear 



Successfully updated crossmatch record. 



7. To delete a crossmatch result record, click the 
appear 



button. The following message will 



Crossmatch Results 
Successfully deleted crossmatch. 

[ Ho records *rere returned as a re*uK of your search. Pl«*»« salact back to try again. ] 
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Feedback 

Accessing and Editing Donor Feedback 

The disposition of organs from every donor is recorded through the Donor Feedback function in UNet 5 ". 
Feedback must be submitted within three working days of the transplant date. 

To view a list of donors who have open (incomplete) feedback, take the following steps: 

1 . Begin your Placement session. (See Beginning a Session in Placement) 



2. Click on the 



Feedback 



button on the left menu. The Open Donor Feedback page is displayed: 



Open Donor Feedback 




Institution 




22P001 - MAOB - Hew England Organ Bank 
Feedb«ck is incomplete for the following donors. 




Donors created more then 30 days ago 




Created Donor ID Donor Name 


Referred From 


Donors created between 5 and 30 days ago 




Created Donor ID Donor Name 


Referred From 


Donors created less than 5 day* ago 




Crested Donor ID Donor Name 

10/X3/2001 ojmoo l Robinson, Ten 


Referred From 

ATlANTICAftE UNION HOSPITAL 
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3. Select a donor from the list and click on the Donor ID. The Report Donor Feedback page will 
display. 



Report Donor Feedback 














FEEDBACK OPEN 

Information for Donor ID: O3M001 

OPOi 22P001- MAOB- Naw England Organ Bank 
Donor Hospital: 220033 - ATLAffTlCARE UNION HOSPITAL 






Histocompatibility Labi 

Donor Nama: 

Data of Rafarral Catli 


1 

Robinson, Tast 

1 


J 




Racov»ry Data: 
Rafarral Only: 


1 

<~YES r NO 






Disposition of Donor Organs 






Organ: 


Disposition (supply code): Code: 


Hatch IDs 


Tx Center: 


Right KJdnay 


1 A\ 


1 J 


1 J 


Laffc Kidnay 


1 Jl 


1 -d 


1 J 



4 . Enter all applicable information . 

5. For Referrals, enter the Date of Referral Call and click on the Referral Only Yes button. A 
referral is when no consent was requested or obtained. After the feedback record has been 
updated, the Referral Only field will be read-only and can only be modified by UNOS. 

6. The histocompatibility lab and recovery date are not required if the disposition for all organs is 
either Consent Not Requested, Consent Not Obtained or Organ Not Recovered is selected for all 
organs from the Disposition. 

If Recovered Not for Tx, Recovered Not for Tx but Not Tx or Transplanted is selected for any 
organ disposition, then histocompatibility lab and recovery date are required. 

7. For donors, a disposition must be entered for each organ type. For organs that were 
transplanted, a disposition Code, Match ID of the match that was used to allocate the organ, and 
the TX Center code of the recipient center are required. Click on the Code and TX Center 
column headings to display information tables. 

8. Click the Update button at the top or bottom of the page to save this information. A message will 
display asking you if Feedback is complete. If you click OK, a message will appear at the top of 
the page that the record has successfully updated. Once completed this record no longer 
appears on the list of Open Donor Feedback. 

Note: The Cadaver Donor Registration (CDR) form will be generated in Tiedi when 
feedback is complete. The Donor Histocompatibility (DH) form will generate as well, as 
long as at least one organ disposition is Recovered not for Tx, Recovered for Tx but not 
Tx, or Transplanted. 
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Payback 

Viewing Payback Transactions 



The Payback section of Placement displays a history of Payback transactions that have been recorded 
for your OPO. 

1 . Begin your Placement session. (See Beginning a Session in Placement) 

button on the left menu. The Payback Accounting Search page is 



2. Dick on the 
displayed. 



Payback 



Payback Accounting Search 






Search usinp the criteria below: 








Payback System: 


UNDS A fcdney Payback (lone-term) aj 
UNOS 8 ICidney Payback [long-term) 
UNOS AB Kidney Payback [long-term] ( 
UNOSOKidhey Payback (tonjHwm) zl 




Tran taction Type: 


& Debti 

P Outstanding 


r Cradits 
P.Cancattad 




Trancaction Data: Batwaan 
I 


and 

I 





3. Choose a Payback System using the up or down arrows to view the list. You can select more 
than one system by holding down the Ctrl key while clicking with your mouse. 

4. Enter search criteria (either Debts or Credits), and check Outstanding or Cancelled. 

5. An optional Transaction Date range may be entered, using the MM/DD/YYYY format. 
Note: The system will automatically fill in the current date as the ending date. 

6. Click on Search to view the Payback Debt Accounting page. 

7. To view further information about a payback transaction, you may click on the Date. 



Payback Debt Accounting for MAOB 








Syatem Date Time From 


Oonor 


Share Date Sent Dora* 


r Share Type 




ID 


Type To ZD 


UNOS MK) 11/02/2000 OSiOltOO IUP 


NKA039 


OMM 
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Expected PTR Data 

PTR (Potential Transplant Recipient) data is entered on every donor/recipient match that is used to 
allocate an organ. This information includes whether the organ was accepted, the date/time the potential 
recipient center was contacted, the name of the individual who accepted/rejected the organ offer and the 
primary reason that the organ offer was rejected by the center. UNef" donor/recipient matches provide 
for this data to be entered directly into the match for every transplant candidate listed on the matcrv The 
match will remain with a PTR status of open or expected until the data is entered I and I the match is ; closed 
at the point that organ offers are stopped. If the PTR data is still open for more than 1 5 days, the data will 
be considered overdue. 

The Expected PTR Data section allows you to view, enter and close matches with open PTR data. 
To access a list of open or expected PTR data, take the following steps: 

1 . Begin your Placement session. (See Beginning a Session in Placement) 



Click on the 
default. 



PTR 



button on the left menu. The Expected PTR Data page will display by 



Expected PTR Data 




Newland Organ Bank - NEOB 




O - 15 Day* ( Current ) 


4 


16-20 Days ( Owsrdoe ) 


0 


• 21 - 25 Days ( Ovardua ) 


0 


26-30 Day* ( Ovardua ) 


0 
40 


Greater than 30 Days ( Overdue ) 


Tnfcal Overdue 


40 


total fcxpected 


44 



Expected PTR data Is grouped by Current and Overdue categories. The Total Overdue category 
displays all PTR data that has been expected for over 1 5 days. The Total Expected category 
includes all of your center's Current and Overdue PTRs. Click on the category of your choice, 
and the applicable PTR Report will display. 



Expected PTR Report 

PTR 0-15 Days (Current) 



Don 2D 

OGL003 
OGL003 
OJP002 



Donor Name 


Org 


Hatch Dt 


Match ID 


10712, 2001 


HL 


10/22/2001 


7*300 


10712* 2001 


LU 


10/22/2001 


72501 


11016. 0000 


LI 


10/16/2001 


72289 



Total Matches : • Donor* z 3 Organs i 6 

Feedback L/X dosed Htssmg 

Match ID Seq# Set* # 

L 1 



4. Click on each listed Match ID to enter PTR data and/or to dose the match. 
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5. The Feedback Match ID column displays a Match ID on which the donor's feedback was 
completed, if applicable. 

6. The L/l column indicates if the donor is a local or import donor. 

7. The Closed Seq # column displays the sequence number at which the match has been closed. 

8. The Missing Seq # column displays the first sequence number on the match that is missing PTR 
information. When you dick on the Match ID, you will be taken directly to this first missing 
sequence number. 

Note: You may click on the ~ button at the bottom right comer of the screen to 

view the definitions for these columns, 

9. Click the Back button to return to the Expected PTR Data screen and to enter PTR data on 
another expected match. 
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PTR Offer Import 

PTR Offer data may be entered into a tab-delimited text file and imported directly into UNet*". The file will 
be imported into the applicable match run, based upon the Match ID and the patient data contained in the 
file. To begin this process, complete the steps for exporting PTR Offers data as described in Exporting 
PTR Data. This file may be opened in a spreadsheet so that data can be entered for the candidates on 
the match, saved as a tab-delimited text file and then be imported back into UNet. The import process is 
a simulation of the manual PTR entry process in UNet. A file layout for the PTR Offers file is found in the 
News section under File Layouts. 

t . After completing the steps for exporting PTR Offers, open the tab-delimited text file as shown in 
the example below. With no PTR data entered on the match, the file will export with only six fields 
populated: Match ID (#1). PTR Sequence Number (#2), Type (#4), SSN (#5), Center Code (#6) 
and Center Type (#7). 



72348 


1 


C 


111223333 


ALUA 


TX1 


72348 


2 


c 


111334444 


ALUA 


TK1 


72348 


3 


c 


222222222 


MOOA 


TX1 


72348 


4 


c 


333333333 


MOOA 


TX1 


72348 


5 


c 


222119999 


MOOA 


TX1 


72348 


6 


c 


999B87777 


MOAB 


TX1 


72348 


7 


c 


999999999 


MOOH 


TX1 


72348 


8 


c 


898999999 


AXUB 


TX1 


72348 


9 


c 


222222277 


BULA 


TX1 


72348 


10 


c 


111111111 


aiMG 


TX1 



Note: If you are opening the text file into a spreadsheet, make sure the fields are formatted 
to be TEXT fields, not NUMERIC fields. A numeric field on a spreadsheet will drop any 
leading zeros in the SSN and may cause problems when importing the data. 



The C in the Type field (#4) of this file indicates that the entered refusal or acceptance information 
Is for the individual candidate. The C can be changed to a T to indicate a transplant center 
refusal, or an R to indicate a range refusal as shown in the example below. 



72346 


1 


T 


111223333 


ALUA 


TX1 


N 


10/18J2001 


moo 


John 


Doe 


921 


72348 


2 


C 


111334444 


ALUA 


TX1 














72348 


3 


9 R 


222222222 


MOOA 


TX1 


N 


10A 8/2001 


2:00 


Sandy 


Doe 


991 


72348 


4 


C 


333333333 


MOOA 


TX1 














72348 


5 


C 


22211 9999 


MOOA 


TX1 














72348 


6 


C 


999887777 


MOOA 


TX1 














72348 


7 


C 


999999993 


MOAB 


TX1 














72348 


8 


C 


888899999 


AXUB 


TX1 














72348 


9 


C 


222222277 


BULA 


TX1 














72348 


10 


C 


777777777 


BING 


TX1 


Y 


10/18/2001 


5:00 


Mark 


Doe 


R Y 



When entering a refusal, the following fields need to be entered: Offer Accept, Post Recovery 
Respond Date and Time, Contact First Name, Contact Last Name and Primary OPO Refusal 
Code. When entering a transplant center refusal, this information should only be entered for the 
transplant center's first potential recipient on the list. This patient's record and all subsequent 
patient records for the same transplant center will be updated with the same refusal information 
when the file is imported. In the example above, sequence numbers 1 and 2 will be updated with 
the same refusal information. 
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For range refusals, enter the Ending PTR Sequence Number in the third field of the file, along 
with the refusal information. The refusal code must be either 906, 991 - 996 or 998. The update 
will be applied to this potential recipient and potential recipients through this number when the file 
is imported. In the example above, a range refusal has been entered for sequence numbers 3 
through 9. 

Note: The PTR Refusal Other Specify field is not displayed in the file example above, but 
must be entered when a code 998 is entered into the Refusal Code field (*12). 

To indicate an organ offer acceptance, enter a Y in the Offer Accept field (#8) of the applicable 
potential recipient. The Post Recovery Respond Date and Time, Contact First Name, Contact 
Last Name, Organ Placed are required. A Y may be entered in the 14th field, if the match should 
be closed at this sequence number. 

2. After all data has been entered, save the file as a tab-delimited text file. 



3- To import the file i nto UNer 5 ", click on the 



PTR 



PTR Offer Impart 



button from the Placement menu. Click the 



button. The Upload PTR Offer Data File screen will display. 



Upload PTR Offer Data File 




Enter Ftl«narn«: 


Browse... | 


I 









4. You may enter the filename and its location or click Browse to select the file to be uploaded. The 
Choose file dialog box ts displayed. 



Look in; QlMatchExportj 



iH OJQ005KI01_687 
§ 03Q005tU04O_920 



-ZJ:*1 



Rename: |OJQ005LU04O.SCO~ 
Ftesoftype: 



| Open | 
Cencd I 



53 11/21/2001 



Placement 



PTR 



5. Locate and select the file to upload, and then click Open. 



Enter Filename; 

jMUmportimand^ Browse... I 



6. Click on the Save button to upload the file. 

7 If you are importing one match run, the UNet server will process your request immediately and 
information about the file will display as shown below. However, when importing multiple match 
runs your request will be sent to the UNet server to be processed overnight. You will receive an 
email when the import request is complete, listing the number of records that processed or did not 
process, and the number of records with errors. 



Information About Th* Uploaded Fife 


reimporting and Exporting fUas\OJQ005LU04O_920.TXT 


Upload ftUnama 


( 3498 bytas ) 


Tottl Records in Rlt 


15 


Tot*l Rtcord* Proctf % td 


15 


Tot»l Rtcord* NotProcts*«d 


0 


Tot*l Rtcords With Enror* 


0 



Note- A range refusal or TXC refusal will be counted as only one record processed, rather 
than counting all the records that were updated with the TXC or range refusal information. 
Also, any existing PTR data entered on the match will not be overwritten by the import 
process. 

8 You may also view the imported PTR information for accuracy by accessing the specific donor 
and match imported. Instructions on accessing a match are described in the Running a Match 
topic. 
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The following file layout Is found in the News section, under the File Layouts option. We have also 
included the table for Organ Placed (field #1 3). 

PTR Offer Export/Import Tab Delimited Text File Structure 



Field Label 


Type 


Values/Notes 


# 




(Len) 




1 


Match ID 


N(10) 


Required 


2 


PTR Sequence Number 


N(10) 


Required 


3 


Ending PTR Sequence Number 


N(10) 


Required for Range Refusal 


4 


Type 


A<1) 


C (Cenddete), T (TXC Refusal), R (Range Refusal) 


5 


SSN 


A(9) 


Required 




Center Code 


A(4) 


Required 


7 


Center Type 


AW 


Required 


8 


Offer Accept 


A(l) 


Y or N, If any other value row is not processed 


9 


Post Recovery Respond Date 


A(19) 


Required ( format MM/DD/YYYY HH: MM ) 


10 


Contact First Name 


A(15) 


First or Last Name required Offer Accept is Y 


11 


Contact Lest Name 


A(25) 


First or Last Name required Offer Accept is Y 


12 


Refusal Code 


H(3) 


Required * Offer Accept is N 


13 


Organ PL~*c*d 


A(2) 


Required * Offer Accept is Y 


14 


Cbse Sequence Number 


A(l) 


Y to dose match at PTR Sequence Number 


15 


PTR Refusal Other Specify 


A(75) 


Requited f Primary OPO Refusal Code is 998 



I 

! 
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Organ Placed Table 









Code 


Organ 


Description 


B 


Kl 


Both Kidneys 


L 


KI 


Left Kidney 


R 


KI 


Right Kidney 


e 


KP 


Both Kidneys 


hi 


KP 


Both Kidneys, Pancreas Islet 


BW 


KP 


Both Kidneys, Whole Pancreas 


I 


KP 


Left Kidney 


LI 


KP 


Left Kidney, Pancreas Islet 


LW 


KP 


Left Kidney, Whole Pancreas 


R 


KP 


Right Kidney 


Rl 


KP 


Right Kidney. Pancreas Islet 


RW 


KP 


Right Kidney, Whole Pancreas 


I 


KP 


Pancreas Islet 


W 


KP 


Whole Pancreas 


I 


PA 


Pancreas Islet 


w 


PA 


Whole Pancreas 


s 


U 


Liver Segment 


w 


U 


Whole Liuer 


s 


IN 


Intestine Segment 


w 


IN 


Whole Intestine 


HR 


HR 


Heart 


HR 


HL 


Heart 


HL 


HL 


Heart, Both Lungs 


B 


LU 


Both Lung 


BS 


LU 


Both Lung Segments 


HL 


LU 


Heart, Both Lungs 


L 


LU 


Left Lung 


LS 


LU 


Left Lung Segment 


LR 


LU 


Left Lung, Right Lung Segment 


R 


LU 


Right Lung 


RS 


LU 


Right Lung Segment 


RL 


LU 


Right Lung, Left Lung Segment 
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Entering Donor Referral Data 

In order to assess the impact of the Medicare and Medicaid Hospital Conditions of Participation for 
Organ, Tissue and Eye Donation on hospital organ donation practices, OPOs are required to provide 
donor hospital-specific data on donor referrals and organ recoveries. This reporting began in September 
2001 for referrals made to your organization during the month of August 2001 . 

On the first day of each month, a new table will be provided for the OPO to record donor referrals for the 
preceding month. To enter the donor referral data, take the following steps: 

1 . Begin your Placement session. (See Beginning a Session in Placement) 



2. Click on the 



Referral Data 



displayed for your center. 



button on the left menu. The Donor Hospital Referral Data page is 



Donor Hospital Referral Data for NBOB - OP1 



2001 (incomplete) 



September (incomplete) 
August (incomplete) 
ApH? (incomplete) 
Manch (incomplete) 



3. Each listed month will be noted as complete or incomplete. Months indicated as incomplete 
require data entry. Months indicated as complete do not require further data entry, although they 
will remain editable if any changes need to be made. Click on the applicable month to display the 
Donor Hospital Referral Data page for that month. 



September 2001 - Donor Hospital Referral Data for NBOB - OP1 



Provider # ▼ , Hospital ▼ 
Sorted by Provider* 
010144 

SPRINGHILL MEMORIAL HOSP 
MOBILE, AL 36608 
010145 

AMI WEST ALABAMA GENERAL HOSP 
NORTHPORT, AL 35476 
030002 

GOOD SAMARITAN MED CTR 
PHOENIX. A2 85006 
070001 

THE HOSPITAL OF ST. RAPHAEL 
NEW HAvm CT 06511 



Referral Eligible Consent Recovered /Transplanted 




HRjO /0 


IN; 0 /0 


KI? 0 /0 


Lis 0 /0 


LUj 0 /0 


PA:0 /0 


HRjO /0 


IN: 0 /O 


KJ: 0 /© 


LI: 0 fO 


LUj 0 /0 


PA:0 /0 


HR:0 /0 


IN: 0 /0 


KI: 0 /O 


U: 0 /0 


LU; 0 /0 


PA:0 /0 


HR:0 /0 


IN: 0 /0 


KI: 0 /0 


LI: 0 /0 


LU: 0 fO 


PA:0 /0 



57 



11/21/2001 



Placement 



Entering Donor Referral Data 



4. The list is grouped by donor hospital provider number, but can be re-sorted by hospital name by 
clicking on the red arrow.. You must enter the number of Referrals, Eligible referrals and 
Consents obtained during the month. Tabbing to each field may help to speed up the data entry 
process. The number of organs Recovered and Transplanted will automatically display on the 
screen. The fields are defined as follows: 

Referral: Any patient who is referred by a donor hospital for consideration of organ, tissue and/or 
eye donation. 

Eligible: Any patient who is referred, evaluated and meets organ donor eligibility requirements. 
An eligible organ donor is defined as follows: 

Any patient aged 70 or younger meeting death by neurological criteria, based on the 
American Academy of Neurology Practice parameters for determining brain death, who 
does not have any of the following indications: 

Tuberculosis 

Human Immunodeficiency Virus Infection with Specified Conditions 
Creutzfeldt-Jacob Disease 
Herpetic Septicemia 
Rabies 

Reactive Hepatitis B Surface Antigen 
Any Retro virus infection 

Active Malignant Neoplasms, except Primary CNS tumors and skin cancers 

Hodgkin's Disease, Multiple Myeloma, Leukemia 

Miscellaneous Carcinomas 

Aplastic Anemia 

Agranulocytosis 

Fungal and Viral Meningitis 

Viral Encephalitis 

Gangrene of Bowel 

Extreme Immaturity 

Positive Serological or Viral Culture Findings for HIV 

Consent: The number of consents that were obtained on referrals meeting organ donor eligibility 
requirements. 

Recovered/Transplanted: The number of organs that were reported as recovered and 
transplanted from the specified donor hospital. This information is obtained from the donor record 
and completed Donor Feedback. 

Note: These definitions can a/so be found by clicking on the Legend button iocated at the 
bottom right corner of the Donor Hospital Referral Data page. 
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5. After entering data in the fields for Referral, Eligible and Consent, click on the Update button to 
save this information. 



Note: If there were no donor referrals from a listed donor hospital during the month, enter 
a zero in the Referral field. The Eligible and Consent fields for the donor hospital will then 
default to zero as you move to the next field. 

If the donor hospital is not in your service area any longer, you may inactivate the donor 
hospital so it will not show up in future lists by following the instructions for Inactivating a 
Donor Hospital Hospitals that are inactivated within a particular month will still display on 
that month's report. This allows any referrals to be reported for the time that the hospital 
was noted as Active in UNet 

Adding a Donor Hospital to the Donor Referral List 

1 . If you received a referral from a donor hospital that is not on your list, you may add the donor 



hospital to this month's report, by clicking on the ^^^^ button. The Provider Search page 
will display. 



Provider Search 

Search to see if Provider number efreedy exists : 




Humbert | 









2. Enter the 6-digit Medicare provider number for the donor hospital and click the Search button. If 
the provider number already exists in UNet SM , the hospital name will appear. Select the hospital 
and click the Add button. More than one hospital can be listed with the same provider number. 
Simply fill out the required fields and click the Add button. The new hospital will display on your 
list. 



Add New September 2001 Referral Provider for MAOB-OP1 

Provider Number: 440184 

Current ProvidTt Hot on R*f»rr«t Urt 
44D1B4 - NORTHSIDE HOSP JOHNSON QTY.TN 37S01 



Add only If Provider Not listed above 



Provider #: ft 
Ntmti * 

Otyi * 

BUU: * 

Zipt * 



440184 



-3 
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If the provider does not currently appear on your list or is not in UNet's list of providers, a screen 
will display for you to add the new provider for this month's report. Enter all required information 
and click the Add button. 



Add New September 2001 Referral Provider for MAOB-OP1 

Provider Number: 123444 

No records return «d from t«*rch. 

Provider * 1234*4 

Heme: » | 

City! ft | 

St*Ut * | ~ 3 

Zip: * | . | 



When searching for a provider number, you will be prompted if the provider is already included in 
your list of donor hospitals, if necessary, you may add another hospital with the same provider 
number by following the steps above. 

3. The newly added donor hospital will appear in the current month's list and a request will be sent 
to have the hospital added to the UNet 814 system's list of provider numbers. If you wish the donor 
hospital to appear on future reports, you will need to add the donor hospital to your list of 
hospitals by following the instructions under Adding/Deleting a Donor Hospital, 
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Placement Form Field Descriptions 
Donor Forms 

Local Cadaver Donor Search Form 

One or more criteria may be entered when searching for a local donor. 

Add Date : Enter inclusive dates for the donor's add date in the boxes labeled "Between" & "and". 
Donor ID : Enter the donor ID number in the selection box. 
Donor Hospital: Select the correct donor hospital. 
Last Name: Enter the donor's last name. 

Age Range : Enter the donor age range in the "Between" & "and". Then select an age unit of years or 
months. 

ABO: Select a blood type. 
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Local Cadaver Donor Form 

The fields on the Local Cadaver Donor form contain demographic and basic clinical information about the 
donors. 

Note: You may edit incorrect data on the form if you have access to do so. Otherwise, you wiii 
only be able to view the form. If you have questions about your security access, contact your 
system administrator. 

lUNQ8.tB&^ - ■ > ■ • - - ZZZH • ■ ZH ■ •- ■ - ZZZ 

OPO; Verify that the OPO provider number printed on the form is the 6-character Medicare identification 
number of the OPO responsible for the management of this donor. A list of valid OPO provider numbers 
is available in the Information Tables section. Also preprinted are the four digit OPO code and the name 
of the OPO, 

Donor Hospital : Select the name of the hospital that originally referred the donor. This is a required 
field. 

Last Name : Enter the last name of the donor who was referred to your OPO as a potential organ donor. 
This is a required field. 

First Name: Enter the first name of the donor who was referred to your OPO as a potential organ donor. 
This is a required field. 

Ethnicity : Select the donor's ethnicity from the selection box. This is a required field. 

Hispanic/Latino: Select only if the candidate is of Mexican, Puerto Rican, Cuban, Central and 
South American and other Spanish cultures or origin. 

Non-Hispanic/Non-Latino: Select only if the candidate is not of a culture or origin described above, 
regardless of race. 

Race : Select ail that apply to indicate the donor's race. This is a required field. 

White: Select for candidates having origins in any of the original peoples of Europe. 

Black or African American: Select for candidates having origins in any of the black racial groups of 
Africa. 

American Indian/Alaska Native: Select for candidates having origins in any of the original peoples 
of North and South America, and who maintain cultural identification through tribal affiliation or 
community attachment. 

Asian: Select for candidates having origins in any of the original peoples of the Far East and 
Southeast Asia. Examples of this area include China, Japan, Korea, and Philippine Islands. 

Native Hawaiian or other Pacific islander: Select for candidates having origins in any of the 
peoples of the Hawaii, Guam, Samoa, or other Pacific Islands. 

Mid-East or Arabian: Select for candidates having origins in any of the peoples of the Middle East 
and Northern Africa. Examples of this area include Egypt, Israel, Iran, Iraq, Saudi Arabia, Jordan, 
and Kuwait. 

Indian Sub-Continent: Select for candidates having origins in any of the peoples of the Indian Sub- 
continent. Examples of this area include India and Pakistan. 
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[MATCH RUN INFORMATION" 



Gender: Select the appropriate field for Male or Female. 

Age: Enter the donor's age. The age must fall between 0 and 99. Then indicate the Years or Months. 

DOB: Enter the date of the donor's birth, using the MM/DD/YYYY format. 

ABO: Enter the appropriate blood group for the donor O, A, B, AB f A1, A2, A1B, or A2B. 

Height: Enter the height of the donor in the appropriate space, in feet and inches or centimeters The 
height must fall between 0 and 7 feet or 1 and 225 centimeters. 

Wejflht: Enter the weight of the donor in the appropriate space, in pounds or kilograms The weight must 
fall between 0 and 440 pounds or 0 and 200 kilograms. 

[MATCH RUNS REQUESTED xte'*^ \ ' X<r\>*±&:' • • ^-^r .-.v-s t,^. 



Check off all matches to be run. To save the record and run these matches. Click the Run Match 
button. 

Kidney 

Kidney/Pancreas 

Pancreas 

Heart 

Heart/Lung 
Lung 
Liver 
Intestine 



ON 



HCV Antibody: Indicate whether the HCV antibody is Positive, Negative or Not Done. 

Hepatitis B Core Antibody: Indicate whether the Hepatitis B core antibody is Positive. Negative or Not 
Done from the selection box. 

HLA (Human Leukocyte Antigen): Indicate the donor's HLA. This must be entered when running 
kidney, kidney/pancreas and pancreas matches. 

Previous Gastrointestinal Disease: Yes if donor had previous gastrointestinal disease. If not, select 
No. If unknown, select UNK. This must be Yes or No when running an intestine match. 

Is there time for a Preliminary Crossmatch? Yes defaulted but may be changed if there is not time for 
a preliminary crossmatch. 

Select crossmatch results: Select any crossmatch trays to be included for screening positive 
crossmatches off of the list. A No crossmatches stored message will appear if there are no crossmatch 
results available. 



[OPTIONAL MATCH RUN INFORMATION 



This information is used to further screen potential recipients off the match run who cannot 
accept a donor kidney after a certain amount of ischemic time, glomerufarsclerosis or serum 
creatinine. 



Warm ischemic time : Enter the time in minutes. 

Cold Ischemic time upon arrival : Enter the time in hours. 
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Glomeruli Observed on Kidney biopsy : Enter Yes or No. 

Percent Glomerular Sclerosis on Kidnev biopsy : Enter the percent amount. 

Peak serum creatinine: Enter the amount in mg/dl. 

Final serum creatinine: Enter the amount in mg/dl 
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Import Donor Form 

The fields on the Import Donor form contain demographic and basic clinical information about the import 
cadaver donor 

Note: If you are unable to access the import donor record, contact the originating OPO to verify 
that Import Access has been given. (See Giving Import Access to Another OPO for more 
information.) 

OPO: Verify that the OPO provider number printed on the form is the 6-character Medicare identification 
number of the OPO responsible for the management of this donor. A list of valid OPO provider numbers 
is available in the Information Tables section. Also preprinted are the four digit OPO code and the name 
of the OPO. 

Donor Hospital: Select the name of the hospital that referred the donor. This is a required field. 

Last Name : Enter the last name of the donor. This is a required field. 

First Name: Enter the first name of the donor. This is a required field. 

Ethnicity : Select the donor's ethnicity from the selection box. This is a required field. 

Hispanic/Latino: Select only if the candidate is of Mexican, Puerto Rican, Cuban, Central and 
South American and other Spanish cultures or origin. 

Non-Hispanic/Non-Latino: Select only if the candidate is not of a culture or origin described 
above, regardless of race. 

Race : Select all that apply to indicate the donor's race. This is a required field. 

White: Select for candidates having origins in any of the original peoples of Europe. 

Black or African American: Select for candidates having origins in any of the black racial groups 
of Africa. 

American Indian/Alaska Native: Select for candidates having origins in any of the original peoples 
of North and South America, and who maintain cultural identification through tribal affiliation or 
community attachment. 

Asian: Select for candidates having origins in any of the original peoples of the Far East and 
Southeast Asia. Examples of this area include China, Japan, Korea, and Philippine Islands. 

Native Hawaiian or other Pacific Islander: Select for candidates having origins in any of the 
peoples of the Hawaii, Guam, Samoa, or other Pacific Islands. 

Mid-East or Arabian: Select for candidates having origins in any of the peoples of the Middle East 
and Northern Africa. Examples of this area include Egypt, Israel, Iran, Iraq, Saudi Arabia, Jordan, 
and Kuwait 

Indian Sub-Continent: Select for candidates having origins in any of the peoples of the Indian 
Sub-Continent. Examples of this area include India and Pakistan. 

I MATCH RUN INFORMATION: 2 ■ .-•"■V w ^' -y^m^^' ^^f^^^^fj 

Gender: Select the appropriate field for Male or Female. 

Age: Enter the donor's age. The age must fall between 0 and 99. Then indicate the Years or Months. 
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DOB: Enter the date of the donor's birth, using the MM/DDATYY format. 

ABO: Enter the appropriate blood group for the donor: 0, A, B, AB, At, A2, A1B, or A2B. 

Height : Enter the height of the donor in the appropriate space, in feet and inches or centimeters. The 
height must fall between 0 and 7 feet or 1 and 225 centimeters. 

Weight : Enter the weight of the donor in the appropriate space, in pounds or kilograms. The weight must 
fall between 0 and 440 pounds or 0 and 200 kilograms. 

[M/TOH RUNS REQUESTED^ ^ ^ ^ ..^ |gfgg| g j 

Check off all matches to be run. To save the record and run these matches. Click the Run Match 
button. 

Kidney 

Kidney/Pancreas 

Pancreas 

Heart 

Heart/Lung 
Lung 
Liver 
Intestine 

lADDmONAii MATCH RUN INFORMATION " ^ S^M^ff^^W^ 

HCV Antibody: Indicate whether the HCV antibody is Positive, Negative or Not Done. 

Hepatitis B Core Antibody : Indicate whether the Hepatitis B core antibody is Positive, Negative or Not 
Done from the selection box. 

HLA (Human Leukocyte Antigen): Indicate the donor's HLA. This must be entered when running 
kidney, kidney/pancreas and pancreas matches. 

Previous Gastrointestinal Disease : Yes if donor had previous gastrointestinal disease. If not, select 
No. If unknown, select UNK. This must be Yes or No when running an intestine match. 

Is there time for a Preliminary Crossmatch? Yes defaulted but may be changed if there is not time for 
a preliminary crossmatch. 

Select crossmatch results : Select any crossmatch trays to be included for screening positive 
crossmatches off of the list. A No crossmatches stored message will appear if there are no crossmatch 
results available. 

jOPTIONAL MATCH RUN INFORMATION ^ U ~~~ '^MMZHEil^^^^MME} 

This information is used to further screen potential recipients off the match run who cannot 
accept a donor kidney after a certain amount of ischemic time, glomerularsclerosls or serum 
creatinine. 

Warm Ischemic time : Enter the time in minutes. 

Cold Ischemic time upon arrival : Enter the time in hours. 

Glomeruli Observed on Kidnev biopsy : Enter Yes or No. 

Percent Glomerular Sclerosis on Kidney biopsy : Enter the percent amount. 

Peak serum creatinine: Enter the amount in mg/dl. 

Final serum creatinine: Enter the amount in mg/dl. 

fc R 11/21/2001 
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Living Donor 

The fields on the Living Donor form contain demographic and basic clinical information about the living 
donor. 

Note: in order to access Living Donor information, the work up transplant center must designate 
on the donor record that your OPO can run a match on that donor. 



OPO: Verify that the OPO provider number printed on the form is the 6-character Medicare identification 
number of the OPO responsible for the management of this donor. A list of valid OPO provider numbers 
is available in the Information Tables section. Also preprinted are the four-digit OPO code and the name 
of the OPO. 

Donor Hospital : Select the name of the hospital that originally referred the donor. This is a required 
field. 

Last Name : Enter the last name of the donor who was referred to your OPO as a potential organ donor. 
This is a required field. 

First Name: Enter the first name of the donor who was referred to your OPO as a potential organ donor. 
This is a required field. 

Ethnicity : Select the donor's ethnicity from the selection box. This is a required field. 

Hispanic/Latino: Select only if the candidate is of Mexican, Puerto Rican, Cuban, Central and 
South American and other Spanish cultures or origin. 

Non-Hispanic/Non-Latino: Select only if the candidate is not of a culture or origin described 
above, regardless of race. 

Race : Select all that apply to indicate the donor's race. This is a required field. 

White: Select for candidates having origins in any of the original peoples of Europe. 

Black or African American: Select for candidates having origins in any of the black racial groups 
of Africa. 

American Indian/Alaska Native: Select for candidates having origins in any of the original peoples 
of North and South America, and who maintain cultural identification through tribal affiliation or 
community attachment. 

Asian: Select for candidates having origins in any of the original peoples of the Far East and 
Southeast Asia. Examples of this area include China, Japan, Korea, and Philippine Islands. 

Native Hawaiian or other Pacific Islander: Select for candidates having origins in any of the 
peoples of the Hawaii, Guam. Samoa, or other Pacific Islands. 

Mid-East or Arabian: Select for candidates having origins in any of the peoples of the Middle East 
and Northern Africa. Examples of this area include Egypt, Israel, Iran, Iraq, Saudi Arabia, Jordan, 
and Kuwait. 

Indian Sub-Continent: Select for candidates having origins in any of the peoples of the Indian 
Sub-Continent. Examples of this area include India and Pakistan. 
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1 MATCH RUN INFORMATION 



Gender: Select the appropriate field for Male or Female. 

Age: Enter the donor's age. The age must fall between 0 and 99. Then indicate Years or Months. 

DOB; Enter the date of the donor's birth, using the MM/DD/YYYY format. 

ABO: Enter the appropriate blood group for the donor: O, A, B, AB t A1 , A2, A1 B, or A2B. 

Height : Enter the height of the donor in the appropriate space, in feet and inches or centimeters. The 
height must fall between 0 and 7 feet or 1 and 225 centimeters. 

Weight : Enter the weight of the donor in the appropriate space, in pounds or kilograms. The weight must 
fall between 0 and 440 pounds or 0 and 200 kilograms. 

Check off all matches to be run. To save the record and run these matches. Click the Run Match 
button. 

Kidney 

Kidney/Pancreas 
Pancreas 
Heart 

Heart/Lung 
Lung 
Liver 
Intestine 

lAPDITlQNAil MATCH RUN INFORMATION r-r <z; ' , V. ; :- , / ' \S '':'{ 

HCV Antibody: Indicate whether the HCV antibody is Positive, Negative or Not Done. 

Hepatitis B Core Antibody : Indicate whether the Hepatitis B core antibody is Positive, Negative or Not 
Done from the selection box. 

HLA (Human Leukocyte Antigen): Indicate the donor's HLA. This must be entered when running 
kidney, kidney/pancreas and pancreas matches. 

Previous Gastrointestinal Disease : Yes if donor had previous gastrointestinal disease. If not, select j 
No. If unknown, select UNK. This must be Yes or No when running an intestine match. j 

Is there time for a Preliminary Crossmatch? Yes defaulted but may be changed if there is not time for 
a preliminary crossmatch. 

Select crossmatch results : Select any crossmatch trays to be included for screening positive 

crossmatches off of the fist. A No crossmatches stored message will appear if there are no crossmatch 

results available. j 

[QRIIONA^^ATCHjRPNJNFORMAIION ^ ..-^v* ' K'Vj&m*r-\ y • " • 1 j 

This information is used to further screen potential recipients off the match run who cannot 

accept a donor kidney after a certain amount of ischemic time, giomeruiarsclerosts or serum 

creatinine. j 

i 

Warm Ischemic time : Enter the time in minutes. j 
Cold Ischemic time upon arrival : Enter the time in hours. 
Glomeruli Observed on Kidney biopsy : Enter Yes or No. 

68 11/21/2001 j 
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Percent Glomerular Sclerosis on Kidney biopsy : Enter the percent amount. 
Peak serum creatinine: Enter the amount in mg/dl. 
Finai serum creatinine: Enter the amount in mg/dl. 
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Test Donor 

The fields on the Test Donor form contain demographic and basic clinical information about the test 
donors. 

iunos mmmmmmmmm^: ^ v. a g •• , \ "JEE -v. ZgME • • lEEMB 

OPO: Verify that the OPO provider number printed on the form is the 6-character Medicare identification 
number of the OPO responsible for the management of this donor. A list of valid OPO provider numbers 
is available in the Information Tables section. Also preprinted are the four-digit OPO code and the name 
of the OPO. 

Donor Hospital : Select the name of the hospital that originally referred the donor. This is a required 
field. 

Last Name : Enter the last name of the donor who was referred to your OPO as a potential organ donor. 
This is a required field. 

First Name: Enter the first name of the donor who was referred to your OPO as a potential organ donor. 
This is a required field. 

Ethnicity : Select the donor's ethnicity from the selection box. This is a required field. 

Hispanic/Latino: Select only if the candidate is of Mexican, Puerto Rican, Cuban, Central and 
South American and other Spanish cultures or origin. 

Non-Hispanic/Non-Latino: Select only if the candidate is not of a culture or origin described 
above, regardless of race. 

Race : Select all that apply to indicate the donor's race. This is a required field. 

White: Select for candidates having origins in any of the original peoples of Europe. 

Black or African American: Select for candidates having origins in any of the black racial groups 
of Africa. 

American Indian/Alaska Native: Select for candidates having origins in any of the original peoples 
of North and South America, and who maintain cultural identification through tribal affiliation or 
community attachment. 

Asian: Select for candidates having origins in any of the original peoples of the Far East and 
Southeast Asia. Examples of this area include China, Japan, Korea, and Philippine Islands. 

Native Hawaiian or other Pacific Islander: Select for candidates having origins in any of the 
peoples of the Hawaii, Guam, Samoa, or other Pacific Islands. 

Mid-East or Arabian: Select for candidates having origins in any of the peoples of the Middle East 
and Northern Africa. Examples of this area include Egypt, Israel, Iran, Iraq, Saudi Arabia, Jordan, 
and Kuwait. 

Indian Sub-Continent: Select for candidates having origins in any of the peoples of the Indian 
Sub-Continent. Examples of this area include India and Pakistan. 

IMAT^RUNINFOR.^^ •• ••. ••. ^- ^^m'f¥^\-., - W :• ^^J^i^mM^SSM 

Gender: Select the appropriate field for Male or Female. 

Age: Enter the donor's age. The age must fall between 0 and 99. Then indicate Years or Months. 
DOB: Enter the date of the donor's birth, using the MM/DD/YYYY format. 
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ABO: Enter the appropriate blood group for the donor O, A, B, AB, A1, A2, A1B. or A2B. 

Height: Enter the height of the donor in the appropriate space, in feet and inches or centimeters. The 
height must fall between 0 and 7 feet or 1 and 225 centimeters. 

Weight: Enter the weight of the donor in the appropriate space, in pounds or kilograms. The weight must 
fall between 0 and 440 pounds or 0 and 200 kilograms. 

|MATCHRUNS"^U6FilD~ • — ^ 

Check off all matches to be run. To save the record and run these matches. Click the Run Match 
button. 

Kidney 

Kidney/Pancreas 

Pancreas 

Heart 

Heart/Lung 
Lung 
Liver 
Intestine 

[ADDITIONAL MATCH RUM INFORMATION • .>- ; ;-' r *r<- 

HCV Antibody: Indicate whether the HCV antibody is Positive, Negative or Not Done. 

Hepatitis B Core Antibody: Indicate whether the Hepatitis B core antibody is Positive, Negative or Not 
Done from the selection box. 

HLA (Human Leukocyte Antigen): Indicate the donor's HLA. This must be entered when running 
kidney, kidney/pancreas and pancreas matches. 

Previous Gastrointestinal Disease: Yes if donor had previous gastrointestinal disease. If not select 
No. If unknown, select UNK. This must be Yes or No when running an intestine match. 

Is there time for a Prelimi nary Crossmatch? Yes defaulted but may be changed if there is not time for 
a preliminary crossmatch. 

Select cro ssmatch results : Select any crossmatch trays to be included for screening positive 
crossmatches off of the list. A No crossmatches stored message will appear if there are no crossmatch 
results available. 

[OPTIONAL MATCH RUN INFORMATION . : = v \ " - — ~" ~ ' -• ^^mrvn 



This information is used to further screen potential recipients off the match run who cannot 
accept a donor kidney after a certain amount of Ischemic time, glomerularsclerosis or serum 
creatinine. 

Warm Ischemic time : Enter the time in minutes. 

Cold Ischemic time upon arrival : Enter the time in hours. 

Glomeruli Observed on Kidney bioosv : Enter Yes or No. 

Percent Gl omerular Sclerosis on Kidney biopsy : Enter the percent amount. 

Peak serum creatinine: Enter the amount in mg/dl. 

Final serum creatinine: Enter the amount in mg/dl. 
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Feedback Forms 



Report Donor Feedback 

The fields on the Report Donor Feedback form contain demographic and basic clinical information about 
referrals and recovered organs. 

Note: To correct data on completed Report Donor Feedback forms, you may contact the Help 
Desk by calling 1-800-978-4334 or emailing unoshelpdesk@unos.org. 

_ . — — — : : ; ; — : — ■ — ..... ..,-^. v ,~- c: > ^ , : 

[FEEDBACK OPEN ' .:, -;...v: . j ■-. •••• •■ ■ - ^ C^^^i^ « 

Information for Donor ID : The Donor ID number is preprinted. 
OPO: The OPO name is preprinted. 



Donor Hospital : The hospital name is preprinted. 
Histocompatibility Lab : Select the appropriate institution from the list. 
Donor Name : The donor's name is preprinted. 

Date of Referral Call : Enter the referral call date in MM/DD/YYYY format. 
Recovery Date: Enter the recovery date in MM/DD/YYYY format. 

Referral Only: Indicate whether or not this is only a referral by selecting Yes or No in the appropriate 
circle. 

Organ : 

Right Kidney 
Left Kidney 

Double/En-bloc Kidney 

Pancreas j 
Pancreas Segment 1 
Pancreas Segment 2 

Liver j 
Liver Segment 1 i 
Liver Segment 2 

Intestine j 
Intestine Segment 1 j 

Disposition (Supply Code) : For each organ that applies, indicate whether the disposition supply code is: j 
Consent Not Requested, Consent Not Obtained, Organ Not Recovered, Recovered Not for Tx f j 
Recovered for TX but not Tx or Transplanted. 

Note; When selecting a disposition supply code for each organ, you will not be able to select a 

whole organ and each of its separate organs simultaneously. For example, when selecting codes 

for a right kidney and left kidney, you will not be able to make a selection for a double/en-bloc \ 

kidney. \ 

* 

Code : Enter the disposition reason code for each organ by clicking the Code link at the top of the j 
column. (See Disposition Reason Codes.) 

\ 
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Match ID : Indicate the appropriate Match ID number from the selection box for each organ. 
Tx Center: Select the correct transplant centers for all transplanted organs. 
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Disposition Reason Codes 



REASON CONSENT NOT REQUESTED 


10 


Donor Age 


11 


Non-heart beating donor (Valid only for HR, LU, IN, PA) 


12 


History of Previous Cardiac Surgery (Valid only for HR) 


13 


History of Severe Cardiac Disease (Valid only for HR) 


14 


History of Lung Disease (Valid only for LU) 


15 


History of Gastro-lntestinal Disease (Valid only for IN) 


16 


History of Diabetes Mellitus (Valid only for PA) 


17 


Pancreatitis (Valid only for PA) 


18 


Acute/Chronic Renal Failure 


21 


Donor Quality 


22 


Donor ABO 


99 ! 


Other Specifv 


REASON CONSENT NOT OBTAINED 


100 


Emotional 


101 


Cultural Beliefs 


102 


Religious Beliefs 


103 


Family Conflict 


i 199 


Other Specify 


REASON ORGAN NOT RECOVERED 


200 


Poor Organ Function 


201 


Cardiac Arrest 


202 


Infection 


203 


Positive Hepatitis 


204 


Positive HIV 


205 


Diseased Organ 


206 


Anatomical Abnormalties 


207 


Vascular Damage 


208 


No Recipient Located 


209 


Donor Medical History 


210 


Donor Social History 


211 


Positive HTLV-1 


212 


Biopsy Findings 


213 


Surgical Damage in OR 


214 


No Local Recover Team 


215 


Organ Refused By All Regional Program 


216 


Organ Refused by All National Program 


217 


Organ Refused by all Programs with Urgent Need 


218 


Ruled Out after Evaluation in OR 


219 


Ruled Out Due to Biopsy 


220 


Ejection Fraction < 50% 
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"1 


rOZ < £UU WIN 0£. L/naiienye 


222 


Hemodynamically Unstabel Donor 


223 


Trauma to Organ 


224 


+ Gram Stain 


225 


Time Constraints 


226 


Medical Examiner Restricted 


299 


Other Specify 


RECOVERED NOT FOR TRANSPLANT 


510 


Recovered for Research 


511 


Recovered for Heart Valves 


512 


Recovered for Pancreas islet Cells 


513 


Recovered for Extra-corporeal Liver 


515 


Recovered only for Purpose Hepacytes 


RECOVERED FOR TRANSPLANT BUT NOT TRANSPLANTED 


503 


Recovered for Transplant: Discarded Locally 


504 


Recovered for Transplant: Shared and Discarded 


505 


Recovered for Transplant: Submitted for Research 


506 


Recovered for Transplant: Sent for Heart Valves 


507 


Organ Exported Outside of U.S. 


508 


Recovered for Transplant: Sent for Pancreas Islets 


509 


Recovered for Transplant: Sent for Ex-corp Liver 


514 


Recovered for Transplant: Sent for Hepatocytes 


TRANSPLANTED 


501 


Organ Transplanted Locally 


502 


Organ Transplanted Shared 
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FROM THE REPORT DONOR FEEDBACK FORM 

Consent Not Requested _ 

Consent Not Obtained 

Organ Not Recovered __ 

Recovered for TX but not Tx 

Transplanted 
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Potential Recipient Refusal Codes 



Code 


Refusal Reason 


| Description 


RECIPIENT RELATED REASONS 


901 


Recipient ill 


recipient too sick to attempt transplant at 
the time of offer 


902 


Recipient Unavailable 


recipient cannot be contacted, not ready for 
transplant or has died at the time of offer 


903 


Recipient refused 


recipient refused transplant at the time of 
offer 


904 


Multiple organ transplant required 


recipient requires multiple organ transplant, 
other required organ(s) not available from 
the specified donor at the time of offer 


905 


Recipient transplanted/inactive 


recipient already transplanted or is on the 
inactive list at the time of offer 


906 


Positive crossmatch 


crossmatch results between donor and 
recipient positive 


907 


HLA mismatch unacceptable 


HLA mismatch between donor and recipient 
unacceptable 


908 


Recipient testing results 
unavailable, not done or 
unacceptable 


recipient requires a crossmatch at time of 
offer, high PRA, no current tissue typing or 
any other recipient testing 


909 


Patient's condition improved, 
transplant not needed 


recipients condition has improved and 
transplant is currently unnecessary 


910 


Recipient Medical Urgency 


recipient bypassed due to medical urgency 
of another recipient (requires written 
verification by transplant surgeon) 


PROGRAM RELATED REASONS 


911 


Heavy workload 


program unable to accept an organ at this 
time due to heavy workload 


912 


Operational 


transportation, logistics, distance, exceeded 
one hour response time or placement time 
constraints related to organ ischemic time 


913 


Surgeon Unavailable 


surgeon currently performing 


GENERAL DONOR ISSUES 


921 


Donor quality 


hypertension, prolonged hypotension, high 
vasopressor/ medication dosage, cardiac 
arrest, evidence of infection/positive 
cultures, non-heart beating, etiology of 
death, donor unstable, donor diabetes, 
other medical history 


922 


Donor age 


donor too old or young 


923 


Donor size/weight 


donor too large or small, weight 
ncompatible with recipient 


924 


Donor ABO 


jonor ABO group 
ncompatible/unacceptable 


925 


Donor social history I 


listory of high risk sexual behavior, alcohol 
Dr IV drug use 


926 I 


Positive serological tests i 


DMV, HBV, HCV, HIV. HTLV, VDRL, etc. 
Jonor testing is positive 
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927 


Drgan Preservation 


method/quality of preservation, length of 
cold ischemic time, length of warm ischemic 
time, possible organ contamination, 
inadequate typing material, 
labeling/packaging problems 


928 


Organ anatomical damage or defect 


surgical damage, non-surgical trauma, 
diseased organ, organ vasculature, enbloc 
kidney's or any other anatomical reason 


ORGAN SPECIFIC DONOR ISSUES: KIDNEY 


930 


Renal function test results 
unavailable, not done or 
unacceptable 


Test results relating to renal function are not 
available or tests relating to renal function 
were not performed 


931 


Elevated creatinine 


donor serum creatinine > 2.0 mg/dl 


932 


Abnormal urinalysis 


presence of protein, WBCs, blood, etc. in 
donor urine 


933 


Abnormal biopsy 


biopsy results indicate donor kidney 
unsuitable for transplant 


934 


Decreased urine output 


urine output < 80 ml/ hour 




ORGAN SPECIFIC DONOR ISSUES: LIVER 


940 


Liver function test results 
unavailable, not done or 
unacceptable 


test results relating to liver function are not 
available or tests relating to liver function 
were not performed 


941 


Rising serum transaminase 


SGOT/AST or SGPT/ALT greater than 2x 
normal 


942 


Abnormal biopsy 


biopsy results indicate donor liver 
unsuitable for transplant 


ORGAN SPECIFIC DONOR ISSUES: HEART 


950 


Cardiac function test results 
unavailable, not done or 
unacceptable 


test results relating to cardiac function are 
not available or tests relating to cardiac 
function were not performed 


951 


Abnormal echocardiogram 


echo showing wall motion abnormalities or 
valvular lesions 


952 


Abnormal coronary angiography 


presence of coronary artery disease 


953 


Abnormal EKG results 


Q-waves, ST-T abnormalities or conduction 
disease 


954 


Abnormal hemodynamics 


elevated filling pressures or reduced 
cardiac output 




ORGAN SPECIFIC DONOR ISSUES: PULMONARY 


960 


Pulmonary function test results 
unavailable, not done or 
unacceptable 


tests results relating to pulmonary function 
are not available or tests relating to 
pulmonary function were not performed 


961 


Abnormal arterial blood gases 


arterial blood gas; pH or pC0 2 or P0 2 are 
outside acceptable ranges 


962 


Abnormal chest x-ray 


evidence of infiltrate, trauma, pneumothorax 
or mass 


963 


Abnormal bronchoscopy results 


evidence of infection, trauma or mass 




OTHER 


991 


Donor Medical Urgency 


potential recipient was by-passed due to 
donor medical urgency or OPO time 
constraints. 


992 


Multi-organ placement 


potential recipient was by-passed for priority 



78 



11/21/2001 



Placement 



Information Tables 







multi-organ transplant 


993 


Directed donation 


potential recipient was by-passed because 
the donation was directed to a specific 
recipient. 


994 


Military donor 


potential recipient was by-passed because 
the organ was from a military donor and 
was directed to a military recipient. 


995 


ALU, Sharing Agreement, Variance 


potential recipient was by-passed due to the 
OPO's alternative local unit, sharing 
agreement or variance. 


996 


Extra-renal placed with kidney 


potential recipient was by-passed in order 
to place the extra-renal organ with the 
kidney recipient from the same donor. 


998 


Other Specify 


Use only if the refusal reason does not fit 
the above categories. Be sure to write in the 
other reason, UNOS staff will review the 
OTHER reason and may recode if 
necessary. 
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H LA Antigen Tables 



HLA A, B, and PR Matching Antigen Equivalences 



A 


EQUIVALENT 


LOCUS 




1 


1 


2 


2,203,210 


3 


3 


Q 


9 


10 


10 26.34.66,6601/2 




11 


19 


19,74 




23 


OA 


24,2403 


OR 


25 


Of\ 




OA 


OR fift 69 


zy 


9Q 


oU 


ou 


31 


O I 






oo 


33 


34 


34,6602 


36 


36 


43 


43 


66 


66.6601.6602,10 


68 


68,28 


69 


69.28 


74 


74,19 


80 


80 


203 


203,2 


210 


210,2 


2403 


2403,24 


*6601 


6601.66.10.26 


*6602 


6602.66.10.34 


** 99 


(Ho eauivalent) 



B 


EQUIVALENT 


DR 


fcWUlVHLEN 1 


LOCUS 




LOCUS 




5 


5.52.53.78 


1 


1,103 


7 


7,703 


2 


2.15,16 


8 


8 


3 


3,17,18 


12 


12 


4 


4 


13 


13 


5 


5,11,12 


14 


14,64,65 


6 


6,13,14 r 1403/4 


15 


15.75.76.77.1304 


7 


7 


16 


16,3905 


8 


8 


17 


17,58 


9 


9 


18 


18 


10 


10 


21 


21,4005,1304 


11 


11,5 


22 


22,54,8201 


12 


12,5 


27 


27 


13 


13,6 


35 


35 


14 


14,6,1403/4 


37 


37 


15 


15,2 


38 


38 


16 


16.2,15 


39 


39,3901/2/5 


17 


17,3,18 


40 


40.61.81,0804 


18 


18,3.17 


41 


41 


103 


103,1 


42 


42 


*1403 


1403,14,6 


44 


44 


M404 


1404,14,6 


45 


45 


** 99 


(No eauivalent) 


46 


46 






47 


47 






48 


48 






49 


49 






50 


50,4005 






51 


51,5102,5103 






52 


52,5 






53 


53.5.5102 






54 


54,22 






55 


55 






56 


56 






57 


57 






58 


58 






59 


59 






60 


60 






61 


61,40 






62 


62 






63 


63 






64 


64,14 






65 


65,14 






67 


67 






70 


70,71,72 






71 


71,70 






72 


72,70 






73 


73 






75 


75,15 






76 


76,15 






77 


77,15 
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78 


78,5 


81 


81 7 40 60 61 48 




703 7 


*0804 


0804 8 


1 OsJH 








*2708 


2708 27 7 


*3901 


3901,39 


*3902 


3902,39 


*3905 


3905.16.39 


*4005 


4005.21,50 


*5102 


5102.51.53 


*5103 


5103.51 


*8201 


8201.45.22.54/5/6 


"99 


(No eauivalent) 



* Indicates an allele; may not have a WHO-approved serologic specificity 
•* Code 99 means not tested 



HLA A, B t and DR Unacceptable Antigen Equivalences 


A 


EQUIVALENT 


B 


EQUIVALENT 


DR 


EQUIVALENT 


LOCUS 




LOCUS 




LOCUS 




1 


1 


5 


5,51,5102/3,52,78 


1 


1,103 


2 


2,203,210 


7 


7,703 


2 


2.15,16 


3 


3 


8 


8,0804 


3 


3,17,18 


9 


9,23,24,2403 


12 


12,44,45 


4 


4 


10 


10.25.26,34,66.6601.6602 


13 


13 


5 


5.11,12 


11 


11 


14 


14,64,65 


6 


6,13,14,1403/4 


19 


•4 A AA OA 0<* OO A *\ "7 A 

1 9,29,30,31 ,32,33,74 


15 


1 5,62.63,75,76,77,1 522 


7 


7 


23 


23 


16 


16,38,39 


8 


8 


24 


24,2403 


17 


17,57,58 


9 


9 


25 


25 


18 


18 


10 


10 


26 


26 


21 


21,49.50,4005 


11 


11 


28 


28,68,69 


22 


22,54,55,56 


12 


12 


29 


29 


27 


27,2708 


13 


13 


30 


30 


35 


35 


14 


14,1403/4 


31 


31 


37 


37 


15 


15 


32 


32 


38 


38 


16 


16 


33 


33 


39 


39,3901,3902,3905 


17 


17 


34 


34 


40 


40,60,61 


18 


18 


36 


36 


41 


41 


51 


(same as DR2) 


43 


43 


42 


42 


52 


3,5,6,11,12,13, 


66 


66,6601,6602 


44 


44 




14,17,18,1403/4 


68 


68 


45 


45 


53 


4.9 


69 


69 


46 


46 


103 


103 


74 


74 


47 


47 


*1403 


1403 


80 


80 


48 


48 


*1404 


1404 


203 


203 


49 


49 






210 


212 


50 


50,4005 






*2403 


2403 


51 


51,5102,5103 






*6601 


6601 


52 


52 






*6602 


6602 


53 


53 










54 


54 










55 


55 










56 


56 










57 


57 










58 


58 
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59 


59 


60 


60 


61 


61 


62 


62 


63 


63 


64 


64 


65 


65 


67 


67 


70 


70,71.72 


71 


71 


72 


72 


73 


73 


75 


75 


76 


76 


77 


77 


78 


78 


81 


81 


703 


703 


*0804 


0804 


*1304 


1304 


♦1522 


1522 


*2708 


2708 


*3901 


3901 


•3902 


3902 


*3905 


3905 


MOOS 


4005 


*5102 


5102 


*5103 


5103 


*8201 


8201 


BW4 


**# 


BW6 


**# 



' Indicates an allele; may not have a WHO-approved serologic specificity 
** Please refer to the end of this section for information 



Equivalents for BW4 and BW6: 



BW4 


5,13,17,27,37,38,44,47,49,51,52,53,57,58,59,63,77,1304,5102,5103 


BW6 


7.8,14,18,22,35,39,40,41,42,45,48,50,54,55,56,60,61,62,64,65,67,70,71, 
72,73,75,76.78.81.703.0804.1522,2708.3901.3902.3905.4005,8201 



82 



11/21/2001 



Placement 



Index 



Index 

A 

ActiveX Toolbar 40 

B 

Beginning a Session in Placement 8 

C 

Closing a Match Run 41 

Crossmatch Results 

Accessing and Editing Crossmatch Results 45 

Adding Crossmatch Results 43 

D 

Disposition Reason Codes 74 

Disposition Supply Codes 76 

Donor Feedback 47 

Donor Hospitals 

Accessing the Donor Hospital List 9 

Adding a New Provider to UNet 12 

Adding/Deleting a Donor Hospital 10 

Inactivating a Donor Hospital 14 

E 

Entering Donor Referral Data 57 

Entering PTR Information 

Entering Organ Offer (PTR) Data ,32 

PTR Offer Import 52 

Range Refusal Button 34 

Tips for Entering PTR Information 35 

TXC Refusal Button 33 

Expected PTR Data 50 

Exporting PTR Data 36 

F 

Form and List Buttons 5 

Form Field Descriptions 

Cadaver Donor 62 

Donor Feedback 72 

Import Donor 65 

Living Donor 67 

Local Donors Search 61 

Test Donor 70 

H 

HLA Antigen Tables 80 

How Placement Works , 2 

I 

Import Access 29 

Import Donors 

Accessing Imported Donors 19 

83 11/21/2001 



Placement u Index 

Giving Import Access to Another OPO 29 

L 

Living Donors 20 

Local Donors 

Accessing an Existing Local Donor 15 

Adding a Local Donor 17 

M 

Match Runs 

Closing a Match Run 41 

Exporting PTR Data 36 

Finding a Specific Candidate on the Match Run 27 

Going to a Specific Sequence Number on the Match Run ..28 

Printing a Potential Recipient List 38 

PTR Offer Import 52 

Running a Match 25 

Viewing Canididate Information ....30 

Menus 3 

P 

Payback 49 

Placement Access 7 

Potential Recipient Refusal Codes 77 

Printing a Potential Recipient List 38 

ActiveX Toolbar 40 

PTR Offer Import 52 

R 

Range Refusal Button 34 

Reason Consent Not Obtained 74 

Reason Consent Not Requested 74 

Reason Organ Not Recovered 74 

Recovered for Transplant but not Transplanted ..75 

Recovered Not for Transplant 75 

Running a Test Match 23 

S 

Score Breakdown 31 

T 

Test Donors „ 21 

Transplanted Codes 75 

TXC Refusal Button 33 

W 

What is Placement? 1 



84 



11/21/2001 



u/iiet 

Usert Manual 



Tiedi 



l!§dif : „ Table of Contents 

Table of Contents 

INTRODUCTION TO TIEDI® 1 

What is Tied!®? 1 

How Tiedi® Works 2 

Screen Elements 3 

Menus 3 

Form and List Buttons 5 

USING THE TIEDI® SECTION 6 

Tiedi® Access 5 

Beginning a Session in Tiedi® 7 

TIEDI FORMS 8 

Forms Generation 8 

Form Status g 

Accessing Forms 10 

Entering Data on Tiedi® Forms 12 

Form Validation 13 

Post Transplant Malignancies Form 14 

Reporting a Transfer 17 

Reporting Interim Death or Graft Failure 19 

Reporting Lost to Follow-up 21 

Viewing Outstanding Forms 23 

IMPORTING AND EXPORTING TIEDI® DATA 24 

Forms Export 24 

Deleting Exported Files 25 

Forms Import 26 

Example Process Flows for Import/Export 28 

Sample Process 1 30 

Sample Process 2 30 

LIVING DONORS 31 

Adding a Living Donor ; 31 

Editing a Living Donor Transplant Event Record 33 

REPORTS 35 



Tied? 



Table of Contents 



Information Displayed on the OPO Report 36 

TIEDI® FORMS 38 

38 

TCR - Transplant Candidate Registration Forms 00 

38 

TCR - Kidney 

TCR -Pancreas ^ 

TCR - Kidney/Pancreas ^ 

TCR - Intestine 62 

TCR -Liver 6g 

TCR -Heart ?4 

TCR - Lung 80 

TCR - Heart/Lung < 

87 

TRR - Transplant Recipient Registration Forms 

TRR- Kidney g3 

TRR -Pancreas ' 

TRR - Intestine 4AC 

. , ^ , . lUo 

TRR - Liver m 

TRR - Thoracic 

120 

TRF - Transplant Recipient Follow-Up Forms 

120 

i 25 

TRF -Pancreas 

TRF - Intestine • <oc 

_„ . . ioo 

TRF - Liver 142 

TRF - Thoracic 

Interim Report of Graft Failure, Death or Lost Form 148 

149 

Transfer Provider Form 

150 

Recipient Feedback 

152 

Living Donor Feedback 

155 

CDR - Cadaver Donor Forms 

155 

CDR - Cadaver Donor Referral Form 

CDR - Cadaver Donor Registration Form J® 

Cadaver Donor Recovery Page 

..166 

Living Donor Forms 

166 

Living Donor Registration 

Living Donor Follow-Up 

172 

Immunosuppression Treatment 

173 

Immunosuppression Treatment Follow-Up 

Post Transplant Malignancies Form 175 

183 

Histocompatibility Forms 

1 83 

Recipient Histocompatibility 

Donor Histocompatibility 

INFORMATION TABLES - 190 



- USHL - Table of Content* 

Primary Diagnosis at Time of Listing Codes 190 

Kidney Codes ...190 

Pancreas Codes 193 

Intestine Codes 194 

Liver Codes 195 

Thoracic Codes 

Cadaver Donor Registration Codes 201 

Reasons Consent Not Requested 20 1 

Reasons Consent Not Obtained 202 

Reasons Organ Not Recovered 203 

Flush Solution 205 

Storage Solution 206 

Organ Disposition 207 

Reasons Organ Not Used for Transplantation 2 08 

Cause of Death Codes 209 

Kidney Transplant Recipient Registration/Follow-Up 209 

Pancreas Transplant Recipient Registration/Follow-Up 2 11 

Liver Transplant Recipient Registration/Follow-Up 213 

Intestinal Transplant Recipient Registration/Follow-Up 215 

Thoracic Transplant Recipient Registration/Follow-Up 217 

Cause of Graft Failure/Retransplant Codes 220 

Kidney Codes 220 

Pancreas Codes 221 

Liver Codes 222 

Intestine Codes 223 

Thoracic Codes t 224 

Organ Procurement Organizations 225 

Hospital Based Organ Procurement Organizations ...225 

Independent Organ Procurement Organizations 226 

Histocompatibility Labs 230 

Hospital Based Histocompatibility Labs 230 

Independent Histocompatibility Labs 235 

Transplant Centers 239 

UNOS Member Transplant Centers 239 

Data Ranges 250 

Potential Recipient Refusal Codes 253 

U.S. Postal State Codes 256 

HLA Antigen Tables 257 



American Journal of Transplantation 2003: 3 (Suppi 4): 13-28 
Blackwell Munksgaard 



Black well Munksgaard 2003 



ISSN 1601-2577 



Data sources and structure 



David M. Dickinson 3 *, Mary D. Ellison 6 and 
Randall L. Webb 8 

^Scientific Registry of Transplant Recipients (SRTR)/ 
University Renal Research and Education Association 
fURREA), Ann Arbor, Ml 

b Organ Procurement and Transplantation Network (OPTN)/ 
United Network for Organ Sharing (UNOS), Richmond, VA 
'Corresponding author: David M. Dickinson, dickinsn© 
urrea.org 



Key words: Data collection, data sources, data structure, 
death ascertainment OPTN, SRTR, statistical analysis, 
transplantation, UNet 

Received 17 September 2002, revised and accepted for 
publication 4 December 2002 



Introduction 

This article discusses a rich resource of data used to 
describe all aspects of transplantation, from donor and 
recipient characteristics to immunosuppression medica- 
tions. These data are used by the SRTR, the OPTN, and 
a wide variety of other researchers as the basis for report- 
ing on the state of transplantation in the United States, as 
well as answering a wide array of research questions. 
They are the source for the figures and tables in the 
OPTN/SRTR Annual Report. They form the basis for 
reporting on both OPTN and SRTR web sites, providing 
medical professionals and patients alike with the answers 
to such critical questions as: How fast are waiting lists 
growing? Which center has experience serving patients 
like me? How quickly might I get an organ if I register at a 
different center, and are my prospects for survival after 
transplant there as good? Finally, these data form the 
basis for extensive analyses in support of policy-setting 
by the Secretary's Advisory Committee on Transplantation 
(ACOT), OPTN/UNOS committees, and other government 
and nongovernment requesters: Is a transplant candidate 
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better off accepting an organ from a less-than-ideal candi- 
date or staying on a waiting list? How do antigen matching 
rules affect racial distribution of organs, and how do they 
affect survival? What are the effects of allowing patients 
to be put on waiting lists at more than one transplant 
center? The many questions that may be asked of the 
transplantation data are to some degree controlled by 
how the data themselves are gathered and arranged. 

It is the goal of this article to further understanding of the way 
transplantation data are collected and organized, in order to 
enable better interpretation of research results, more acute 
awareness of data limitations, and clearer concepts of how 
new analyses might proceed. This article is intended for an 
audience of researchers in the transplant community: both 
those who use existing research and those who create new 
analyses with these data. By examining the sources, quafity, 
and organization of the different types of transplant data 
available, we hope to stimulate new exploratory initiatives 
and help researchers with study design — as well as improve 
the understanding of existing results. 

A fundamental step in describing the data available for 
research on transplantation is to conceptualize the range 
of information available and to organize it into areas of 
research interest. The first section of this article previews 
the final research database by showing how the diverse 
collection of data are organized in records representing the 
different types of 'units of analysis' of interest to a 
researcher, saving a detailed discussion of the sources 
for each type of record for later sections. We describe 
how such a wide range of sources is reorganized from 
their original format suiting their original purposes— mostly 
organ allocation but also Medicare billing, Social Security 
Administration benefits, etc. — to a format better adapted 
to the support of research questions. Just as is the case in 
designing a research database, it is useful to begin 
describing this database by considering how the table 
organization will facilitate answering a series of interesting 
research questions. 

The remaining sections of the article describe the sources 
of the underlying data, how they are collected, and how 
they fit into the framework outlined above. In the second 
section, we focus on data collected by the OPTN for the 
purposes of both organ allocation and transplantation 
research. This section focusses on the historical and tech- 
nical development of these data collection systems, with 
an emphasis on how changes and quality control meas- 
ures in these systems have improved the quality of 
data available. In this discussion we hope to acquaint 
researchers with the particular strengths and weaknesses 
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present in many of the primary data elements. We also 
point out the context in which these data were originally 
collected, which may be different from how they are used 
for research. 

In the final section of the article, we describe in more 
detail the 'secondary' data sources incorporated into the 
research database used by the SRTR. These secondary 
sources are used to augment the primary data reported by 
OPTN members, both to improve the quality and to 
expand the scope of the data. We describe some of the 
sources available, and examine their impact on answering 
several research questions. 

Further discussion of the types of analyses supported by 
these data can be found in 'Analytical Approaches for 
Transplant Research' (1), a companion article in this 
supplement, as well as in Appendix H of the 2002 OPTN/ 
SRTR Annual Report. 



Organizing Data for Research 

Data structure and units of analysis 

This section describes the organization structure of many 
sources of data assembled for transplantation research. 
Though the examples here are taken directly from the 
SRTR, they are generic in application: They might resem- 
ble data organized for similar purposes by the OPTN or any 
other researcher who obtains these data from either the 
SRTR or the OPTN. 

We should first review some terms used to describe data 
organization. Data are arranged into separate 'tables', 
often SAS or SPSS datasets or SQL tables. Each of 
these tables, which are 'relational' in that they may be 
linked one to another, contains a series of rows or records, 
each representing one item of interest such as a person, 
transplant recipient, or organ. Each column, known as a 
field or variable, represents a different characteristic of 
that record. In a table describing transplants, for example, 
these columns include such things as age at transplant, 
type of organ, and information about the transplant center; 
in a table describing each organ available from a deceased 
donor, these fields might include the eventual disposition 
of the organ, how many candidates refused the organ, or 
the reason that it was not recovered. 

The roles in the 'relationship' between two tables are 
often described as 'parent' and 'child': for each record in 
a child table, there is a linked record in its parent table. 
There may, however, be some parent records with no 
child records, while other parent records have many child 
records. For example, in the relationship between a trans- 
plant (parent) and transplant follow-up (child), a transplant 
may have no follow-up forms filed, or one, or two, or 1 0; 
yet all follow-ups must be linked to one and only one 



transplant. Extensive parent-child organization is useful 
for maintaining data integrity in applications that keep 
track of constantly changing values, such as the OPTN 
organ allocation procedures, though it may make research 
with these data computationally intensive. 

Instead, when preparing analysis files, consideration is 
given to the 'unit of analysis' that may be of interest to 
the researcher. Different tables are organized for different 
research questions, using different units of analysis as 
rows in each table. More emphasis is placed on creating 
a table where a single record carries a wide variety of 
information about a record of inherent interest to the 
researcher, and less consideration is given to the effi- 
ciency of data storage, waiting list management, or alloca- 
tion matches. Data from many sources and related tables 
may be summarized and attached to the record of inter- 
est. For example, many researchers want to examine 
transplants (unit of analysis) and their post-transplant sur- 
vival, such as Tables X.9 in each organ-specific section of 
the data tables in the Annual Report. A table in which each 

- row represents a transplant may be augmented with data 
summarized from the related tables of follow-up sources, 
such as each recipient's latest status as alive or dead and 
the date of that status. A table in which all of this informa- 
tion is summarized on a single record is easier to analyze 
than assembling information from multiple parent and 
child rows in multiple tables. However, for other purposes, 
such as counting immunosuppressive medications during 
follow-up periods, it may still be useful to use individual 

- records for each follow-up period. Figure 1 shows a useful 
scheme of organizing these data into a 'record of interest', 
drawn from the example implemented for analyses by the 
SRTR. This figure also gives an idea of the breadth of 
commonly used units of analysis and the relationships 
between them. 

One central organizing element in this structure is the 
Person Linking Table (PLT), in which each record is a 
person — perhaps a living donor, transplant candidate, or 
transplant recipient. The PLT facilitates a common patient 
identifier to be assigned to records in all other tables, linking 
persons on the basis of Social Security numbers (SSNs), 
names, dates of birth, and other person-level information, 
while accounting for many of the mistakes in entering 
these fields. The maintenance of this identification roster, 
with aggregated identification information compiled from all 
data sources, has two primary functions. First, it facilitates 
a system of matching to both external data sources and 
other records within OPTN data, such as for persons who 
receive multiple transplants or even for donors who later 
become recipients. Second, the common patient identifier 
provides an anonymous means of person identification 
for researchers without revealing names or SSNs. The 
matching system is described in greater detail below. 

The other table entities in Figure 1 relate to a specific 
subject of interest for research: candidacies, donors, 
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Figure 1: Transplantation research data organization, primary and secondary sources. Source: SRTR. 
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Figure 2: Data submission and data flow, primary and secondary sources. Sources: SRTR and OPTN. 
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transplants, and the components thereof. In addition, this 
figure documents some of the primary and secondary data 
sources which may contribute to each table. Further detail 
regarding the specific data collection instruments for the 
primary data collection by the OPTN is shown in Figure 2. 

Analysis tables 

Though the PLT is useful for keeping track of summarized 
person-level information and matching to newly incorpor- 
ated records or data sources, it is often not directly useful 
for analyses. Instead, using a common patient identifier, 
data from this table are added to separate tables more closely 
based on 'units of interest' for analyses such as the following: 

• transplant candidates (e.g. waiting time, mortality on 
the waiting list); 

• transplant recipients (e.g. graft survival, complication 
rates, incidence of tumors); 

• donors (e.g. donation rates, donor characteristics that 
influence graft survival, etc.). 

Each of these, in turn, has its own child tables as well as 
both primary and secondary sources of data. Later in this 
article we discuss, in more detail, the primary data collec- 
tion methods and secondary data sources for these tables. 

Analysis tables: candidates 

'Time to Transplant' tables, the second in each of the 
organ-specific data tables sections of the Annual Report, 
make use of a unit of analysis that represents a candidate 
registration. Such a table may also be useful for measuring 
mortality on the waiting list, either at the center-specific 
level or for comparison to post-transplant mortality in evalu- 
ating the efficacy of transplant for a given patient. 

The 'candidate registration' table includes persons who are 
registered on the OPTN waiting list as well as additional 
candidates who have received a living donor organ, even if 
they have never been placed on the waiting list. The vast 
majority of candidate information comes from the candi- 
date registration and waiting list information collected by 
the OPTN. This table presents information about candi- 
dates during the time they are waiting to receive an 
organ, such as the center at which they are listed, when 
they are listed, factors affecting organ allocation like blood 
group or medical urgency status, and when they are 
removed from the list and for what reason (death, transfer 
to another center, transplant, etc.). Often, fields in the 
operational data are transformed to more closely reflect 
events of interest for analyses. For example, to facilitate 
time to transplant analyses, waiting list removal dates for 
transplants are set to the transplant dates when the 
candidates cease to be eligible for allocation — though in 
practice a patient may be removed from the waiting list at 
any time from the date an organ is allocated until days after 
it has been transplanted. 



As Figure 1 indicates, the candidate file is primarily based 
on data that are entered as part of waiting list mainten- 
ance by the transplant centers, as well as the Transplant 
Candidate Registration (TCR) Form. These data may also 
be augmented with data from other data sources as 
described below. Most notably, additional mortality 
sources are very important, because transplant programs 
are not required to track and report outcomes after 
removal from the waiting list (other than removal for trans- 
plant). These sources may include the Social Security 
Death Master File (SSDMF), Centers for Medicare and 
Medicaid Services data on End-Stage Renal Disease 
patients (CMS ESRD) for kidney and kidney-pancreas 
patients, and the National Death Index (NDI). 

Some analyses make use of candidate data recorded at a 
narrower level than the usual record of interest. For exam- 
ple, the first relational 'child' table shown connected to the 
candidate file is the waiting list 'status history' table: for 
each registration on the waiting list, at least one record 
exists in the status history table. This table records char- 
acteristics that may change during the course of waiting 
list tenure, such as medical urgency status or Model for 
End-Stage Liver Disease (MELD) score for liver candi- 
dates. Each record in this table is associated with a time 
at which those characteristics began and ended. Such a 
file is useful for finding a patient's status on any given day, 
calculating the accumulated time at each status at any 
point in time, or examining how trends in a patient's 
MELD score might affect mortality. From an organ alloca- 
tion perspective, on the other hand, only the current 
urgency status and a running total of time accumulated 
at (or above) each status are important. The status history 
analysis table is created by examining histories of changes 
to the operational waiting list that are recorded as part of 
the audit process in the operational organ-allocating data- 
base, noting all changes that involve status, and augment- 
ing this file with nonoverlapping start- and end-dates for 
the span of each set of characteristics. Therefore, an 
analyst may move through this file in a temporal fashion 
for each patient, examining current status for each patient 
and facilitating a time-dependent model such as one that 
associates status on a given day with outcome (mortality 
or transplant) on the same day. 

The status history file is a highly focused accounting of the 
candidate file; the 'candidate-person' table, conversely, 
aggregates candidate records into a much wider view 
based on individual persons. In the first candidate table 
described, and for the purposes of organ allocation, a 
person is given a registration record each time he or she 
is entered onto a waiting list at a transplant center; a given 
"person might have several registrations, either in 
sequence or concurrently. By using the common patient 
identifier, one can construct 'candidacies' that span regis- 
trations, separated for each person only by transplants. A 
candidacy in this file starts from the time a patient is first 
put on the waiting list at any center and ends when that 
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patient receives a transplant (from a living or deceased 
donor) from any center, is removed for the last time, or 
dies. A second candidacy might begin for the same patient 
when he or she is relisted after a failed transplant. The 
candidate-person table also has a status history sub-table, 
whose records have similar information and purpose to 
the status history child table of the registration-based 
candidacy file, but with the additional function of reconcil- 
ing differences between status recorded for different list- 
ings and summarizing the number of concurrent listings at 
any point in time. 

The candidate-person approach is consistent with an 
'intent-to-treat' analysis. In such an approach, the original 
goal of any wait-listing is to transplant the patient, doing so 
at any center is a success for that patient, and the 'waiting 
time' that a patient cares about is the time from his or her 
first listing until transplant. By contrast, the registration- 
based candidacy table may be more relevant when evalu- 
ating a center's ability to move a patient through the 
waiting list process. 



Analysis tables: transplants 

A subset of the candidate registrations make their way 
into the transplant table, including persons who have 
received a transplant from the waiting list as well as 
those receiving a living donor transplant. The transplant 
file is used by analysts wishing to characterize trends in 
volume and characteristics of patients receiving trans- 
plants {Table 4 in the organ-specific data tables sections 
of the Annual Report), as well as analyses examining 
post-transplant survival (Tables 8 and 9, Graft and Patient 
Survival). 

This table draws primarily upon information from the 
Transplant Recipient Registration (TRR) Form, filed by 
centers following each transplant. The table includes char- 
acteristics of the patient at the time of transplant and the 
transplant operation itself. For ease of analysis, character- 
istics of the donor are added, as well as donor-recipient 
interactions, such as calculated HLA mismatch scores, 
blood compatibilities, and whether the organ was 'shared', 
based on the relationship between the organ procurement 
organization (OPO) recovering the organ and the trans- 
plant center. 

The primary transplant table also includes summarized 
information from the child table 'transplant follow-up'. 
Data in this table come from the post-transplant follow- 
up forms collected 6 months after transplant (except for 
thoracic organs) and then at each yearly anniversary. 
These follow-up forms contain items such as hospitaliza- 
tion, current lab values, functional status, and other develop- 
ing medical conditions. This table, in turn, has specific 
sub-tables of its own, recording details of immunosup- 
pression treatments and developing malignancies, for 
example. 



The data gathered during the organ allocation process and 
follow-up forms are strengthened further: Similar to the 
candidates table, several secondary follow-up sources per- 
taining to death, graft failure, retransplant, and resumption 
of dialysis are summarized and added to the transplant 
table, as described in Figure 1 . These important elements, 
and their ramifications for data completeness, are 
described later in this article. 

Analysis tables: donors 

Donor information is shown separately for living and 
deceased donors — not only because such different pri- 
mary information is collected by the OPTN for each 
group, but also because each relates to its own set of 
secondary data elements and its own analyses. Indeed, 
much of the donor information that is common to both 
types of donors and useful for analysis of transplant out- 
comes has already been added to the transplant file itself. 
The donor files might be more frequently used for such 
things as analysis of organ disposition and reasons for 
nonrecovery of organs from deceased donors, or for 
examining the post-donation outcomes of living donors. 

For each deceased donor, up to 1 1 whole organs or organ 
segments may be recovered (one heart, two kidneys and 
lungs, and up to two segments each for pancreas, intes- 
tine, and liver). This recovery information is stored in a 
sub-table of the deceased donor table, 'organ disposition', 
giving reasons for nonrecovery or nonconsent, and even- 
tual disposition of each organ. The information from this 
table is taken directly from forms filed by OPOs. The third 
section of the data tables details disposition (e.g. local 
transplant, shared transplant, used for research), reasons 
for nonuse, and reasons for nonrecovery of organs. Ana- 
lysts might also use such a table to glean additional infor- 
mation regarding unused organs or might wish to examine 
organ recovery data available in OPO-specific format. 

In addition to organ disposition data, researchers may 
combine deceased donor information with external 
sources of mortality data for the general population such 
as information from the National Center for Health Statis- 
tics (NCHS). Combining such sources allows researchers 
to compare availability of potential donors in certain areas 
to the number of organs recovered, or to evaluate suc- 
cessful methods used to obtain family permission for 
organ recovery. The use of OPO forms and NCHS data is 
discussed below. 

Living donors are also included in the PLT, to facilitate 
matching with internal and external data sources, and 
allow for additional ascertainment of events such as 
death, dialysis, or registration on a waiting list. For living 
donor follow-up, transplant centers are asked to report at 
6 months and 1 year, though compliance and reliability are 
not as good as they are for recipient follow-up. Many 
centers submit follow-up forms for living donors as 
required, but are less likely to see these donors, who are 
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often healthier or live elsewhere and may therefore be 
more difficult to track. For living donors from 2000, though 
90% have an appropriate 1-year follow-up form filed, 42% 
of these living donors are coded as 'lost to follow-up' — 
indicating that, even when complying with OPTN follow- 
up requirements, centers do not know what has happened 
to these patients. 

Though possible secondary data sources are listed 
(SSDMF, CMS ESRD, NDI), lack of completeness and 
accuracy in living donor identification information jeopard- 
izes the use of these external sources. Before April 1, 
1994, SSNs were not collected for living donors. Since 
then, more than half of SSN matches to the SSDMF are 
highly improbable (based on review of names and implaus- 
ible relationships among birth dates, death dates, and 
dates of organ recovery), indicating that there is probably 
significant inaccuracy in these identifiers even when they 
are available. 



Primary Data: The OPTN Data Collection 
System 

Data system components 

The OPTN data collection system and database were 
developed in 1986 by the United Network for Organ Shar- 
ing (UNOS, the OPTN contractor) after the 1984 National 
Organ Transplant Act called for the creation of a national 
network for organ sharing and a scientific registry to moni- 
tor the clinical progress and effectiveness of transplant- 
ation. The information systems themselves have 
undergone many changes with regard to technology, 
data collection processes, and data content. The system 
consists of three components: the national transplant 
waiting list, the donor-recipient match process, and the 
data collection 'forms'. The first two together can be 
thought of as the allocation data, as these are the data 
essential for the day-to-day operation of distributing 
organs to potential recipients. The 'forms', collected with 
somewhat less urgency, are intended more for research 
and administration purposes. 

Figure 2 shows data flow into both the OPTN and SRTR 
databases, focussing on the different mechanisms for sub- 
mission of data by OPTN members to the OPTN database. 
The figure shows data separated into two types: that used 
for organ allocation, on the left, and that used for research, 
education, and administration, on the right. This figure also 
serves as a full list of the major data collection instruments 
in place for OPTN members. Copies of the forms may be 
found in Appendix I of the 2002 OPTN/SRTR Annual Report. 

The initial process of data collection, as well as organ 
allocation, begins with the waiting list. At the time a 
patient is placed on the waiting list, essential data are 
captured for donor matching and allocation. Such data 
have always included such variables as blood type and 



medical urgency status. These data can and, in some 
cases, must be revised and updated by personnel author- 
ized to access the waiting list. Although the transplant 
program controls the list for its patients, it may authorize 
the OPO or even the histocompatibility laboratory to 
perform maintenance on it. Adding a patient to the waiting 
list prompts the generation of the TCR, which is sent to 
the transplant program to collect additional information 
about the candidate that is used for purposes other than 
matching and allocation. 

The donor-recipient match process begins when an OPO 
enters a donor into the system. Donor data essential for 
matching and allocation are captured and a 'match run' for 
each organ type available (e.g. kidney, heart, etc.) is gen- 
erated. This programming accomplishes several functions 
simultaneously: it reflects organ distribution and allocation 
policies in place at the time of the match, identifies all 
patients that are clinically compatible with the donor, 
assesses their geographical appropriateness based on 
donor location, and assigns priority rankings. The product 
is a match run for each organ type, available electronically 
and in printable formats to the OPO for organ placement. 
If authorized by the OPO, a histocompatibility lab may run 
a match in lieu of the OPO. 

There are several subsystems within the donor-recipient 
match process that collect data and generate donor forms. 
At the time of the match, the Potential Transplant Recipi- 
ent (PTR) Form is created on the match run itself. This 
data form is made available for the OPO to record the 
refusal reasons (such as donor quality, recipient unavail- 
ability, or positive crossmatches) for potential recipients 
ranked higher on the list than the ultimate recipient(s). This 
information is provided by the OPO based on organ offer 
responses from transplant programs. Transplant centers 
may then validate, via UNet, the refusal reasons entered 
by the OPO during a 15-day period after the match is 
completed by the OPO. 

The OPO is required to report the results of donor organ 
placement efforts through a process called 'donor feed- 
back'. Upon completion of the donor feedback (itself a set 
of forms), the Cadaver Donor Registration (CDR) and 
Donor Histocompatibility (DH) Forms are generated to 
gather donor data for research and reporting purposes. 
OPO personnel complete and return the CDR forms, 
while the tissue-typing laboratory serving the donor hos- 
pital provides data requested on the DH form. 

Transplant recipients must be removed from the waiting 
list within 24 h of receiving an organ. This completes the 
'recipient feedback process', and two additional forms 
collect additional research and reporting information: the 
TRR Form, completed by the transplant program, and the 
Recipient Histocompatibility (RH) Form, submitted by the 
recipient center tissue-typing laboratory. When a hospital 
reports a living-donor transplant for a patient who was 
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not on the waiting list, a TCR, TRR, and RH form are 
generated for the recipient. A Living Donor Registration 
(LDR) and DH Form are generated for the donor. The 
transplant program completes the recipient forms and 
the tissue-typing laboratory completes the histocompati- 
bility forms. The Living Donor Follow-up and Transplant 
Recipient Follow-up Forms are generated and transmitted 
to the transplant program 6 months after transplant 
and every 1-year anniversary of the transplant. If a post- 
transplant malignancy is reported on a follow-up form, a 
Post-transplant Malignancy Form is generated and sent 
to the transplant program. If a patient is reported as 
retransplanted, dead, or lost to follow-up, no further 
follow-up forms are generated for the specific transplant 
event. If a pancreas or kidney graft failure is reported, then 
follow-up on the patient is continued for only 2 more 
years. For all other organs, no further follow-up forms 
are generated. 

Data collection forms submitted by transplant programs 
are completed by a variety of hospital employees, includ- 
ing nurses, clinical coordinators, clerks, and administrative 
assistants. A hospital's 'data coordinator' can be any of 
these types of personnel. Since the inception of the OPTN 
database in 1986, financial pressures on hospitals have 
increased, as has the volume of data forms for most 
hospitals. Some programs devote significant resources 
to OPTN data submission activity; others less so. The 
implications of budgetary pressures for data quality have 
been a primary concern of the OPTN/SRTR Data Working 
Group and the OPTN Data Advisory Committee, two new 
committees supporting data-related OPTN process and 
policy development. During a comprehensive 2-year pro- 
cess since the fall of 2000, these committees have been 
able to significantly streamline and reduce the amount of 
data to be collected by the OPTN. Final changes will be 
implemented once approved by the OPTN/UNOS Board 
and the Federal Office of Management and Budget. It is 
hoped that a lower data burden at the facilities will lead to 
higher quality for a smaller amount of data, focusing on 
the most scientifically relevant items. 

History of the data collection system 

Figure 3 shows some of the evolution of the OPTN/UNOS 
data systems. UNet SM , an Internet-based application for 
waiting list maintenance, donor-recipient matching, and 
forms-based data collection for research and administra- 
tion, was implemented on October 25, 1999. Before UNet, 
the most significant modifications to the data system 
occurred in 1990 and 1994. In 1990, the waiting list and 
data forms systems were converted from a flat file data 
system to a relational database, making the data easier to 
manage with regard to both storage and analysis. Based 
on almost 7 years of use, analysis, and reporting by the 
OPTN/UNOS committee system, the UNOS staff, and the 
Federal Government, a large number of data elements 
were added to the data collection forms. These additions 
required a second database conversion in April 1994. All 



OPTN/UNOS committees provided input during the forms 
revision process. Since that time, an incremental process 
of adding data fields has resulted in gradual increases in 
data volume. 

In 1996, UNOS created a client-server application on a 
Lotus Notes platform called Tiedi® (transplant information 
electronic data interchange) to collect transplant data elec- 
tronically rather than on paper. This was the first effort to 
transfer to OPTN members the ability to maintain the 
submission of their own data collection forms and to 
eliminate the need to mail paper forms to UNOS. With 
this system, as many as 50% of centers and laboratories 
were using Tiedi for data submission. Since its use was 
not a required method of data submission, some stayed 
with the existing paper-based submission and manual data 
entry system. 

When UNOS implemented UNet in 1999, the degree of 
security increased significantly, requiring user-specific 
passwords and encryption for all patient-identified data 
transmission. An on-site UNet security administrator 
assigns access privileges and controls user access at 
each hospital. All data are now transmitted via the Internet 
with secure socket layer (SSL) technology and 128-bit 
encryption. As well, the utilization of electronic sub- 
mission of data among members has increased greatly: 
currently, 3 years following the implementation of an 
Internet-based data system, 97% of OPTN centers, 
laboratories, and OPOs enter their research and adminis- 
tration forms electronically. 

UNet has tightly integrated all three components of the 
data system. The waiting list and the forms databases 
were combined into a single longitudinal relational data- 
base (Microsoft SQL Server), and the data systems were 
no longer parallel and compartmentalized but seamlessly 
integrated. Within 6 months, the percentage of OPTN 
members using the new system to access and manage 
the waiting list increased from an estimated 40% to more 
than 90%. Currently, all waiting list management is per- 
formed on UNet (mostly by transplant center personnel) 
rather than by requesting changes by phone through the 
UNOS Organ Center. 

For certain wait-listed patients, waiting list data manage- 
ment is not only available to the hospitals but in some 
cases is required in order to avoid automatic allocation 
status downgrades. For example, a patient listed as liver 
allocation Status 1 must be recertified weekly for that 
status by the hospital, on the basis of current laboratory 
data. Additionally, since July 8, 2002, status justification 
forms for liver and heart (Status 1 A and 1 B) must be sub- 
mitted through the UNet system. 

Before UNet, the donor-recipient match run yielded a 
computer-printed data list. With the implementation of 
UNet, the match list became a data file from which data 
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1986-90 


1990-94 


1994-96 


1 996-99 


1999 to Present 




Pre-OTIS 


OTIS 


OTIS + Tied*® 


UNet 8 " 


Waiting List Management 


Communication 


Phone to Organ Center with paper back up and validation. 
Some facilities use terminal emulation via modem 


Member online 
(Web-based) 


Donor-Recipient Matching 


Communication 


Terminal emulation and modem or 
phone to organ center and faxed to OPO 


OPO generates online 
(Web-based) 


Data Collection Forms 


Mode of 
submission 


Paper. Manual data entry at UNOS. 
Line prompt entry 


Electronic forms 
added 


Web-based submission. Paper 
forms phased out 


Submission 
prompting 


Member- 
initiated 


Electronic events prompt form generation. 
Forms mailed by UNOS 


Electronic events prompt blank 
web-form generation 


Edit checks 


Few 


Checks added over this period, data 
verification reports by mail 


All fields validated 
electronically. Verification 
reports by mail 


System 


Storage system 


VMS flat 
files 


VMS 
relational 
database 


VMS relational database, 
Lotus Notes 


Microsoft SQLServer 
Relational Database 


Component 
integration 


None 


Match and forms linked. 
WL addition initiates TCR 


All systems 
completely integrated 


Security 


One password per center. 
No encryption during transmission 


User-specific passwords. Full 
128-bit encryption 



Figure 3: OPTN/UNOS data system evolution. OTIS = Organ Transplant Information System, Tiedi = Transplant Information Electronic 
Data interchange, UNet = Internet-based data collection system. Source; OPTN. 



variables could later be extracted for analysis. This change 
also allowed the OPTN to integrate PTR data with the 
match output. Another advantage of UNet is that matches 
for all organ types can now be run simultaneously — rather 
than serially — as was necessary on the previous mainframe 
computer system. The flexibility of match runs that are files 
rather than printed lists had allowed OPOs to view, print, 
and export matches as data files that can be stored in 
databases at the OPOs and in the OPTN data system. 

With regard to data submitted on forms for research and 
administration (e.g. TCR, TRR, and TRF Forms), the transi- 
tion to an Internet-based system has had a number of 
implications. Forms are generated and appear as 
'expected forms' when the member is in UNet. The mem- 
ber can complete the electronic forms manually or import 
data from a local electronic records system. UNet forms 
include fewer text fields than the paper forms did, utilizing 
pick-lists and reducing the need for visual edit checks in 
these fields by UNOS data quality staff. Most other fields 
have programmed acceptable responses and standard 
data ranges. Immediate edit checks and cross-field edits 
for some variables reduce data errors by allowing the data 
collector to pay immediate attention to problems as the 
data are entered. Forms cannot be electronically marked 
as 'validated' (complete) until all fields have been entered 
and have passed a series of edit checks. Data quality has 
become largely the responsibility of the system and of 
OPTN members, and submission via UNet has eliminated 
the mailing back and forth of paper forms containing erro- 
neous or incomplete data. 



Measures of internal data quality 

The quality of the data within the OPTN database is 
affected by the timeliness, completeness, and accuracy 
of the data submitted by members. Also pertinent in any 
discussion of quality is whether the variables collected are 
sufficient and appropriate (and not superfluous) for the 
needs of the OPTN, the SRTR, the Federal Government, 
and the public. These measures of data quality are cur- 
rently being evaluated by a new committee, the joint 
OPTN/SRTR Data Working Group. The most recent 
OPTN and SRTR contracts required that such a committee 
examine data quality in detail and advise the OPTN/UNOS 
Data Advisory Committee and Board on necessary revi- 
sions. Other aspects of OPTN data quality are addressed 
by activities of the SRTR, internal operations at UNOS, and 
the OPTN data submission policy compliance process. 



Approaches to improve data timeliness and 
completeness 

Until June 30, 2002, OPTN data submission policies 
required that 99% of data forms due from an OPTN mem- 
ber be submitted within a year of the dates they were 
expected. In most cases, the expected date for a form 
was 60 days after it was generated (e.g. transplant date or 
transplant anniversary). In an effort to improve the time- 
liness of data collected by the OPTN, the Health 
Resources and Services Administration (HRSA) of the 
Department of Health and Human Services included in 
the current OPTN contract a requirement that 100% of 
each program's data be complete within 6 months of the 
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Table 1: Transplant Recipient Follow-up (TRF) form submission at 1 year after form generation, by transplant program type and volume 

Percentage of TRF forms submitted within 1 year of expected date 

Organ and No. of 

program volume* programs 0% 1-33% 34-66% 67-99% 100% 



Heart 



Low (0-9) 


44 


0.0% 


4.5% 


6.8% 


29.5% 


59.1% 


Medium (10-17) 


44 


0.0% 


6.8% 


4.5% 


40.9% 


47.7% 


High (18+) 


42 


0.0% 


11.9% 


9.5% 


57.1% 


21.4% 


Total 


130 


0.0% 


7.7% 


6.9% 


42.3% 


43.1% 


Kidney 














Low (0-24) 


78 


1.3% 


6.4% 


7.7% 


32.1% 


52.6% 


Medium (25-59) 


83 


1.2% 


6.0% 


6.0% 


41.0% 


45.8% 


High (60+) 


83 


0.0% 


6.0% 


13.3% 


45.8% 


34.9% 


Total 


244 


0.8% 


6.1% 


9.0% 


39.8% 


44.3% 


Liver 














Low (0-21) 


37 


0.0% 


5.4% 


16.2% 


35.1% 


43.2% 


Medium (22^5) 


39 


2.6% 


7.7% 


10.3% 


35.9% 


43.6% 


High (46+) 


39 


2.6% 


10.3% 


2.6% 


38.5% 


46.2% 


Total 


115 


1.7% 


7.8% 


9.6% 


36.5% 


44.3% 



Source: OPTN database. "Transplants performed in 2000. 



form's expected date. The OPTN/UNOS Board approved 
this policy change in November 2001 . 

Table 1 shows transplant centers' compliance with the 
follow-up data submission policy in place before June 30, 
2002.. These results are stratified by the volume of trans- 
plants performed at each program in the previous year. 
The data show a number of high-volume programs in 
compliance with the previous policy. For example, 83 
high-volume kidney programs (35%) submitted their year 
2000 follow-up forms within a year of their expected dates 
and, as such, had perfect compliance. Although some low- 
volume programs show poor compliance, there is a slight 
tendency for smaller programs to have better compliance 
with follow-up policies. In response to concerns that the 
accuracy of publicly reported program-specific survival 
rates may be affected by incomplete outcomes data in 
the OPTN database, the SRTR has undertaken an effort to 
obtain missing OPTN outcomes data from other sources, 
as described below. Overall, 87% of TRFs were submitted 
in compliance with policy, as shown in Table 2. In contrast, 
nearly 95% of RH forms generated in 2000 were 
submitted on time. OPTN member compliance with data 
submission policy is an area of increasing focus for the 
UNOS Policy Compliance Department and the 
OPTN/UNOS Membership and Professional Standards 
Committee, which is exploring more direct means to ensure 
compliance. 



Approaches to improve data accuracy 

Monitoring the accuracy of data in the database involves 
edit checks during the data entry process, internal pro- 
cesses at UNOS, and a collaborative effort of the OPTN 
and the SRTR. The UNOS Help Desk takes calls from 
members who find inaccuracies within fields that can 



only be modified by UNOS staff (e.g. transplant dates 
and SSNs). UNOS also creates computer programs that 
search for inconsistencies in the database and generate 
discrepancy reports. For example, one program compares 
data entered into the age, height, and weight fields for 
each patient, looking for cross-field entries that seem 
unlikely or impossible. Other such programs compare 
entries for employment status, education, and age, and 
check patient functional status for consistency with med- 
ical urgency status. In addition, the SRTR delivers similar 
discrepancy reports to the OPTN each month to raise 
further data quality issues. When problems with records 
arise, data quality specialists resolve them through UNet 
and direct contact with transplant centers. Problems that 
affect a large number of records can sometimes be 
resolved through programmed edits, but other fields 
must be addressed individually. Fields in which 
UNet allows incorrect data entry are identified on an 
ongoing basis, and UNet edit checks are regularly revised 
to reduce opportunities for data entry errors. Recent 
efforts to detect database problems have included 22 
different discrepancy reports and 38 different database 
checks. Some of these reports and checks are rerun on 
a regular basis to correct recurring errors. Others involve 
one-time projects to resolve problems, such as those 
related to previous database conversions or modifications. 

Database checks performed to detect problems in the 
data have included checks among living-donor and recipi- 
ent records for invalid SSNs (e.g. strings of 0s or 9s 
sometimes used when SSNs are unknown at the time of 
data entry) and checks for inconsistent entry of date of 
birth, race, gender, and blood type across records for 
patients wait-listed at multiple transplant programs. 
Other checks have included searches for persistent wait- 
ing list registrations when programs have reported 
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Table 2: Data submission compliance rates, by form type, for forms generated during the year 2000 





No. 


No. received 


Compliance 


Form type 


expected 


in compliance 


rate 


Transplant Candidate Registration (TCR) 


46199 


41 761 


90.4% 


Transplant Recipient Registration (TRR) 


26073 


23320 


89.4% 


Transplant Recipient Follow-Up (TRF) 


172448 


150014 


87.0% 


Living Donor Registration (LDR) 


6096 


4939 


81.0% 


Living Donor Follow-Up (LDF) 


2294 


1739 


75.8% 


Post-transplant Malignancy (TMR) 


628 


628 


100.0% 


Cadaver Donor Registration (CDR) 


12817 


11872 


92.6% 


Recipient Histocompatibility (RH) 


23004 


21815 


94.8% 


Donor Histocompatibility (DH) 


13316 


12454 


93.5% 



Source: OPTN database. 



patients as having been transplanted and searches for 
transplant records when waiting list registrations have 
been removed for reason of transplant. With the addition 
of a number of new features and data entry checks in 
UNet, many types of database checks are no longer 
necessary. This has resulted in more efficient use of 
time for staff and in improved data quality. 

In addition to a number of special discrepancy reports 
generated through the UNet application and sent via 
UNet to OPTN members for problem resolution, the 
OPTN also generates and prints a number of reports that 
it mails to each member. These mailings include a monthly 
summary of the member's overdue forms, a monthly list 
of the member's reported living-donor transplants, and 
semiannual confirmation reports of transplants, living- 
donors, and deceased donors. Each member also receives 
an annual report of its data submission compliance rates, 
according to form type. Some aspects of data accuracy 
cannot be addressed by electronic data entry edits, pro- 
grammatic data checks, or efforts to ensure compliance 
with data submission policies. Experience with OPTN data 
suggests that certain variables within the database may be 
more reliable than others. In an effort to learn more about 
the difficulties of providing accurate data for certain fields, 
UNOS staff have conducted preliminary on-site transplant 
program audits using actual patient charts to check the 
accuracy of information provided to UNOS. Results of the 
audits suggest that data variables involving objective infor- 
mation readily available in medical charts and requiring 
little or no interpretation (e.g. race, age, and gender) tend 
to be highly accurate. Other types of information (e.g. 
patient education level, employment status, and functional 
status) are more difficult to find in the charts. Results of 
various serological tests of interest to the OPTN are 
largely available in the charts, but details regarding testing 
methods and timing of the test in relation to the transplant 
procedure, also of interest to the OPTN, are more difficult 
to interpret from the chart. Such observations by UNOS 
staff and OPTN members alike are being factored in as the 
Data Working Group and Data Advisory Committee con- 
sider data collection revisions. 



Secondary Data Sources 

Reasons for additional sources 

Other sources besides the data collected by the OPTN 
provide important information that may be linked to these 
data or used in conjunction with them. Additional data 
sources help determine the areas of weakness in compli- 
ance and accuracy of the data collection described above; 
they can also expand the scope of available research. For 
example, additional data sources can help researchers 
perform the following important tasks: 

• Ensure complete ascertainment of mortality and graft 
failure, improving precision of analyses and answering 
questions about the quality of transplant data submitted 
by a transplant center. 

• Expand measurement of events not collected by the 
OPTN, such as death after a candidate is removed 
from the waiting list. 

• Provide additional ascertainment of other events, such 
as malignancies from local cancer registries across the 
country. 

• Offer measures of potentially available donors for evalu- 
ating donation practice patterns. 

• Establish correlations between measures not concur- 
rently used in organ allocation, such as between the 
four medical urgency status groups used before 2002 
(1, 2A, 2B, 3) and the more continuous computed 
MELD scores for liver recipients used since then. 

The PLT and patient matching 

The SRTR-ESRD PLT was developed by the SRTR to 
provide a central repository for patient identifying data 
from various sources and to provide a common patient 
identifier that can be used to link patient data across those 
sources. The records in the PLT include persons found in 
primary OPTN data, as well as those found in Medicare 
data about patients with ESRD. There is a large overlap 
in the population covered by these two databases, as 
kidneys account for about two-thirds of the transplant 



22 



American Journal of Transplantation 2003; 3 (SuppL 4): 13-28 



Data sources and structure 



candidates and recipients in the SRTR database. Because 
most ESRD patients qualify for Medicare benefits, most 
kidney transplant recipients and candidates (usually on 
dialysis) also are found in the CMS ESRD data. 

The development of the PLT was a collaborative effort of 
University Renal Research and Education Association 
(URREA) and the Kidney Epidemiology and Cost Center 
(KECC) of the University of Michigan. HRSA, the agency 
that oversees the OPTN and SRTR, and the Centers for 
Medicare and Medicaid Services (CMS) have an inter- 
agency agreement for sharing organ transplantation data. 
Under this agreement, CMS discontinued its separate 
collection of kidney transplant data, the OPTN became 
CMS's source for transplant data, and HRSA gained 
access to the Medicare ESRD data. Since 1988, first as 
the United States Renal Data System (USRDS) and then 
under various CMS contracts, KECC has developed and 
maintained a database that integrates almost all of the 
CMS data on ESRD patients. URREA and KECC, as the 
SRTR, have integrated transplant patients into this com- 
mon database by matching to existing patients where 
applicable, and by adding records for transplant patients 
not already in the ESRD portion of the database. 

The PLT data are organized around people, rather than 
around organs, diseases, or events. These people are 
the set of donors and candidates; some candidates 
become transplant recipients, and some donors may 
become candidates themselves. At the basic unit of a 
person, the SRTR assembles information from a variety 
of sources: 

• candidate, donor, and transplant information (including 
follow-up) collected by the OPTN; 

• mortality and dialysis information from CMS for ESRD 
patients abstracted from institutional and physician/ 
supplier claims, medical evidence forms, and death 
notifications; 

• death information from the SSDMF; 

• death information from the NDI. 

To handle incomplete or erroneous identifiers in the 
diverse data sources used, patients are added to the PLT 
using a 'fuzzy' matching system that considers SSNs, 
names and nicknames, dates of birth, and other identifying 
information (e.g. gender, transplant dates, and death 
dates) — all with allowances for common coding mistakes 
such as transpositions or entry of the wrong birth year. For 
example, the first two records listed in Table 3 would be 
linked as the same person because of the similar name 
and SSN, along with date-of-birth evidence. However, the 
third person, perhaps a family member using the same 
Medicare billing number, receives a distinct patient iden- 
tifier on the basis of conflicting evidence, despite having 
the same SSN and last name. 
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Table3: Sample records for sorting Into PLT 





Date of 




Name 


SSN birth Source 


Person J D 


Joe Smith 


123^5-6789 03-06-1968 Kl candidate 


1 


Joseph 


123-46-5789 03-06-1968 Living Kl 


1 


Smyth 


recip. 




Lynda Smith 


123-45-6789 05-12-1965 Kl donor 


2 



Source: SRTR. 

Ascertainment of graft and patient survival 

The most important use of additional data sources has 
been in investigating the completeness of mortality data 
reported by transplant centers to the OPTN. In recent 
years, the reliability of such figures as the center-specific 
post-transplant survival calculations published by the SRTR 
has been called into question (2,3) because some centers 
have had poor return rates for post-transplant follow-up 
forms. Complete ascertainment of mortality is imperative 
for comparing post-transplant outcomes to the outcomes 
of those on dialysis or the waiting list. It is important to use 
multiple sources because no single data source is complete 
by itself, and because data submitted directly by transplant 
centers are subject to bias in reporting, either toward or 
away from sicker patients. For example, a center might 
have more contact with sicker patients, thus making it 
easier to report on them; on the other hand, it is possible 
that some centers could lose track of these patients more 
easily — or some might even attempt to 'fool the system' by 
underreporting patients with poor outcomes. 

Linking within OPTN data 

Although this is not a data source that is 'external' to the 
OPTN data collection system, a modification to the data 
from the structure established for organ allocation can be 
useful for research. This modification is made possible by 
the central organization of a patient record and common 
patient identifier in the PLT table. Within the organ alloca- 
tion and data collection database, each waiting list regis- 
tration and transplant is treated as a separate entity, as 
linkage is not necessary for allocation. 

For patients with multiple waiting-list candidacies or multiple 
transplants, crucial data such as the patient's death date may 
be reported for only the last candidacy or transplant. The 
common patient identifier allows data for the same patient 
to be linked together within the SRTR database. For a patient 
with multiple transplants or candidacies, this allows a death 
date reported in follow-up for the last transplant or reported 
on a final candidacy after graft failure to be made available 
when analyzing any of the previous transplants. Within the 
OPTN database, linkage across multiple listings or trans- 
plants is accomplished primarily through SSN. 

SSDMF 

The SSDMF, publicly available from the Social Security 
Administration (SSA), contains over 70 million records 
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created from reports of death to the.SSA. Records are 
reported for both beneficiaries and noribeneficiaries; 90% 
are reported by family members and funeral homes, the 
remainder are reported by state and federal agencies, 
banking institutions, postal authorities, etc. This file 
includes the following information on each decedent: 
SSN, name, date of birth, date of death, ZIP code of last 
residence, and ZIP code of lump sum payment- Because it 
may miss some noribeneficiaries, the absence of a particu- 
lar person in this file does not prove the person is alive, 
and the deaths of children are more likely to be missing. 
Of the deaths included in the SSDMF, more than 98% 
are complete by the end of the third month after a death 
date. 

Every month, the SRTR adds new information from the 
SSDMF into the patient table. For each patient in the PLT, 
the SRTR looks up the SSN for that patient in the SSDMF. 
When found, the names and birth dates are checked 
before the SSDMF death date is recorded in the patient 
table. 

CMS ESRD database 

Medicare data, described above in relation to the PLT file, 
provide an additional source of death data for ESRD 
patients. They also can provide pretransplant dialysis his- 
tory and a source for inferring graft failure from return to 
dialysis. Because of Medicare rules, most of these data 
center on ESRD patients, though data can also be 
obtained for any patients in the PLT with failure of other 
organs who appear in the Medicare data. 

The Renal Beneficiary and Utilization System (REBUS) 
system at CMS is the primary CMS ESRD database, and 
includes data from a number of sources that are useful in 
organ transplantation research. REBUS obtains death 
dates for beneficiaries from the Medicare Enrollment 
Database (EDB), as well as from the ESRD Death Notifica- 
tion Form, which includes the cause of death. As a source 
of dialysis history, the ESRD Medical Evidence Report is 
filed for all patients starting dialysis, certifying that a 
patient has ESRD and indicating the cause of ESRD and 
the date of first dialysis. This form may also indicate the 
date of a transplant, the date of return to dialysis after a 
transplant, and the date of death. Since 1995, dialysis 
facilities have been required to complete this form for all 
new dialysis patients, not just those eligible for Medicare. 

In addition to these forms, detailed Medicare claims data 
are obtained separately from REBUS and are updated 
annually. These claims data are another source of date of 
death, date of first dialysis, and the date of return to 
dialysis after a transplant. 

NDI 

Compiled by the National Center for Health Statistics 
(NCHS), the NDI contains data from death certificate 
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information submitted by state vital statistics agencies. 
Researchers may use this file to determine whether sub- 
jects have died and to facilitate obtaining actual death 
certificates from the state agencies. Researchers may 
submit a list of subjects to NCHS, which in turn matches 
with the NDI using a 'fuzzy' matching algorithm similar to 
that described above for the PLT. Resulting match possi- 
bilities are returned to the researcher, who makes the final 
decision about the quality of each match. 

While the NDI is the most complete source of death data 
used by the SRTR (missing approximately 5% of deaths in 
the United States), it has a number of significant limita- 
tions. First, the NDI is updated only annually. Taking into 
account the time for NCHS to process the death certifi- 
cates and run matches, the reporting time lag is 1-2 years 
after the death date. Fees for NDI matching are also sub- 
stantial. 

A second significant limitation is a restriction on how NDI 
data may be used. Agreements between the NCHS and 
the state agencies that collect the death certificates pro- 
hibit using the data for administrative or regulatory pur- 
poses. This means that while these data may be used for 
national mortality figures, they may not be reported back 
to transplant centers or be used for center-specific 
reports. 

The OPTN and SRTR have carried out a test of the useful- 
ness of the NDI for supplementing and benchmarking the 
completeness of the OPTN death data and other available 
sources of death data. The OPTN prepared a file of 
patients for whom the OPTN has no data since 1999 and 
who were alive at the last known time point. This file was 
matched against all years of the NDI. The results of this 
exercise are included in the discussion of all extra mortal- 
ity sources below. 



Implications of secondary sources for mortality 

The OPTN data alone capture most of the deaths among 
patients in the SRTR database, and some deaths are cap- 
tured only by the OPTN data, especially when multiple 
records within the OPTN data are linked and considered. 
The SSDMF and ESRD sources provide important add- 
itional coverage at low cost. The NDI provides some add- 
itional coverage, although at higher cost and with a longer 
time lag. Table 4 shows the frequency of update, usual 
reporting lag, and cost associated with these various 
sources of death ascertainment. Table 5 shows the 
contribution made by each of these sources to the ascer- 
tainment of deaths among transplanted patients. For most 
patients, death dates are found in more than one source; 
in these cases, the sources are checked in the order in 
which they appear (from left to right) in Table 5: 

• OPTN Primary (death reported with the first transplant 
recorded); 
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• OPTN Secondary {death ascertained from a subsequent 
waiting list registration or transplant); 

• SSDMF; 

• CMS ESRD; 

• NDI (searched last because it is the most difficult, 
restricted, and expensive source). 



Any patient with an 'OPTN Primary' death date is classi- 
fied with that source. If the patient does not have an 
'OPTN Primary' death date, then the other sources are 
checked in the indicated order until a date is found, and 
each death is attributed to only one source. For example, if 
a person's death date is found only in the SSDMF and 
CMS ESRD, then the patient is classified with SSDMF. 
The 'contribution' of a source is the proportion of all 



Table 4: Additional sources of transplant outcome data 


Source of 


Frequency of 


Reporting lag 


Added 


Used in 2002 


death data 


SRTR update 


after death 


cost 


Annual Report 


OPTN data 


Monthly 


1-15 months after death; may not be reported until 


None 


Yes 






next annual follow-up form 






CMS ESRD data 


Monthly 


1-6 months 


None 


No 


SSDMF 


Monthly 


3 months 


Low 


Yes 


NDI 


Yearly 


1-2 years 


High 


No 



Source: SRTR. 



Table 5: Distribution of deaths from 1991 to 1999 among transplant recipients by source of death date, organ, survival time after first 
transplant, and patient age at death 

Source of death date 





Deaths 


Primary 
OPTN 


Secondary 
OPTN 


SSDMF 


CMS 
ESRD 


NDI 


All 


45561 


77.3% 


6.9% 


14.3% 


0.7% 


0.8% 


Kidney and pancreas (K/P) 














All 


25859 


68.9% 


6.0% 


22.9% 


1.3% 


0.9% 


Kidney 


24607 


68.1% 


6.1% 


23.6% 


1.4% 


0.9% 


Pancreas 


69 


60.9% 


17.4% 


17.4% 


1.4% 


2.9% 


Kidney-pancreas 


1183 


87.2% 


3.6% 


8.8% 


0.2% 


0.3% 


Non-K/P organs 














All 


19702 


88.3% 


8.0% 


3.0% 


0.0% 


0.6% 


Liver 


8412 


81.5% 


14.6% 


3.1% 


0.0% 


0.8% 


Intestine 


173 


82.1% 


13.3% 


2.9% 


0.0% 


1.7% 


Heart 


7649 


93.0% 


2.8% 


3.6% 


0.0% 


0.6% 


Lung 


3147 


94.7% 


3.1% 


1.8% 


0.0% 


0.3% 


Heart-lung 


321 


94.1% 


4.0% 


1.2% 


0.0% 


0.6% 


Kidney and pancreas 














Died within 1 year of transplant 


4504 


94.1% 


1.4% 


4.3% 


0.1% 


0.2% 


Died 1-2 years after transplant 


2157 


82.2% 


3.3% 


13.4% 


0.6% 


0.6% 


Died 2-3 years after transplant 


2288 


76.0% 


4.3% 


18.1% 


0.9% 


0.8% 


Died 3-4 years after transplant 


2459 


71.6% 


5.4% 


20.9% 


1.3% 


0.9% 


Died 4-5 years after transplant 


2370 


65.5% 


6.8% 


25.4% 


1.0% 


1.3% 


Died > 5 years after transplant 


12081 


56.0% 


8.5% 


32.4% 


2.0% 


1.1% 


Non-K/P organs 














Died within 1 year of transplant 


9651 


90.3% 


9.0% 


0.5% 


0.0% 


0.1% 


Died 1-2 years after transplant 


2401 


90.4% 


7.4% 


1.7% 


0.0% 


0.5% 


Died 2-3 years after transplant 


1737 


88.7% 


7.8% 


2.8% 


0.0% 


0.7% 


Died 3-4 years after transplant 


1437 


88.4% 


6.4% 


4.6% 


0.0% 


0.6% 


Died 4-5 years after transplant 


1177 


86.5% 


5.9% 


5.6% 


0.0% 


2.0% 


Died > 5 years after transplant 


3299 


81.3% 


7.1% 


9.9% 


0.0% 


1.7% 


Kidney and pancreas 














Age > 21 years 


25458 


68.8% 


5.9% 


23.1% 


1.3% 


0.9% 


Age < 21 years 


401 


76.8% 


11.7% 


9.7% 


0.5% 


1.2% 


Non-K/P organs 














Age > 21 years 


17642 


88.7% 


7.3% 


3.3% 


0.0% 


0.7% 


Age < 21 years 


2060 


84.6% 


14.0% 


0.7% 


0.0% 


0.6% 



Source: SRTR data analyses, August 2002. 
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deaths that were identified by this source 'first', and will 
depend on the order chosen. Therefore, a small contribu- 
tion from a secondary source (the CMS ESRD data, for 
example) does not mean that that source identifies few 
deaths; it may simply identify the same deaths as sources 
searched earlier. 

Table 5 reports on transplant recipient deaths identified by 
any of the sources and occurring from 1991 through 1999. 
This range of years was chosen because 1999 was the 
last year for which the NDI was searched. For patients 
who have had more than one transplant, transplant date 
(for computing survival time) and organ are determined 
from the first transplant. Statistics for kidney and pancreas 
patients are reported separately from those receiving 
other organs because the data differ substantially for the 
two groups. These differences are due to the existence of 
an alternative treatment (dialysis) for kidney failure, differ- 
ences in data collection (e.g. OPTN-based follow-up only 
for 2 years after graft failure), and the availability of alter- 
native sources of information (CMS ESRD). 

The OPTN data provided information on only 75% of the 
deaths for kidneys and pancreata (K/P) but 96% of deaths 
for all other organs. However, for deaths in the first year 
after transplant, the OPTN data cover 99% of the non-K/P 
deaths and 95% of the K/P deaths. This explains in part 
the result reported in the 'Analytical Approaches' article 
that, for many transplant programs, center-specific sur- 
vival is diminished little, if not improved, when SSDMF 
data are considered- Thus for 1-year survival, the OPTN 
data are quite good for the nation as a whole, but the 
remaining sources are particularly important for longer 
follow-up times. 

The contribution of the SSDMF increases steadily as the 
survival period increases. For non-K/P organs, the contri- 
bution of the SSDMF rises to 6% after 5 years. For K/P 
organs, the increase is much more rapid, rising to 13% for 
1-2 years following transplant and exceeding 32% for 
5 and more years. The rise in the SSDMF contribution as 
survival time increases suggests that the transplant cen- 
ters lose contact with patients as the time since transplant 
increases, and the higher percentages for K/P organs sug- 
gest that this happens even more rapidly for K/P recipi- 
ents. This difference presumably occurs because dialysis 
is available as a treatment after a kidney graft failure, while 
transplantation is the only definitive treatment available for 
the failure of most other organs. Thus kidney recipients 
may be more likely to move out of the transplantation 
system and are less likely to be followed by a transplant 
center. 

As expected, the CMS ESRD data contributed no deaths 
to the organs other than kidney and pancreas. Even with 
kidney and pancreas, the incremental contribution of the 
CMS ESRD data is only 1%. The NDI makes an even 
smaller contribution of 0.8%, or 352 deaths out of 



45561. It thus appears that the combination of the 
OPTN data and the SSDMF does a very good job of 
identifying deaths. 

Table 5 also shows results for two age groups, divided at 
age 21. For both organ groups, secondary OPTN sources 
contribute almost twice as much in the younger group 
than in the older group. This may be because younger 
patients are better candidates for a retransplant after a 
graft failure and thus are more likely to be relisted and 
retransplanted. The SSDMF has a much larger contribu- 
tion in the older group than in the younger, although the 
SSDMF still contributes 9.7% of the deaths among the 
younger kidney and pancreas recipients. This may be a 
combined effect of the SSA covering more of the older 
patients and the OPTN data sources covering more of the 
younger patients. 

When examined in this order, the CMS ESRD and NDI 
sources each contribute less than 1 % of the deaths: 336 
CMS ESRD deaths and 352 NDI deaths out of a total of 
45561 . The largest contribution of the NDI for a subgroup 
is only 2%. We expected the NDI to make a larger con- 
tribution among younger patients on the assumption that 
the SSDMF would miss many younger patients, but the 
contribution in this group is minimal. It is not clear whether 
the other sources catch most of the deaths in this group or 
whether the NDI also is missing deaths among younger 
patients. 

So far, we have shown that overall ascertainment of mor- 
tality looks good when all sources are considered. Next 
we address the question of whether all sources are neces- 
sary. Specifically, if we have good mortality data from 
secondary sources, how important is the OPTN member- 
ship as a data source for mortality? 

Table 6 is similar to Table 5 but orders the death sources 
differently in order to show the deaths uniquely contribu- 
ted by the OPTN data after deaths from the SSDMF and 
CMS ESRD data have been counted. When examined in 
this order, the OPTN data contribute 14% of the deaths. 
For kidney and pancreas, the OPTN data contribute only 
5% for patients aged 21 and over, but they contribute 
27% for patients under 21. For other organs, the OPTN 
data contribute 21% for the older group and 73% for the 
younger group. While these contributions decline with 
time, for deaths 5 or more years after transplant the 
percentages are still 17% for organs other than kidney 
and pancreas. 

We conclude that at the national level, the OPTN data are 
very complete for 1-year survival, and that the SSDMF and 
CMS data are important for longer-term survival analyses, 
particularly for kidneys. Using the NDI is probably not 
worth the additional expense. While we do not know 
what proportion of actual deaths is missed by all these 
sources taken together, the fact that the two sources 
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Table 6: Distribution of deaths from 1991 to 1999 among transplant recipients by source of death date, time after first transplant, and 
patient age at death, with alternate ordering of sources to show unique contribution of OPTN data 

Source of death date 









rye 


ri unary 


C &e*f\ r\ o n / 
jcLUl lUdly 






Deaths 


ooUMr 


ccon 
bonU 




Url IN 


NUI 


All 


45561 


82.2% 


2.8% 


12.7% 


1.5% 


0.8% 


Kidney and pancreas (K/P) 


25859 


89.6% 


4.8% 


4.3% 


0.4% 


0.9% 


Non-KP organs 


19702 


72.5% 


0.2% 


23.8% 


2.9% 


0.6% 


Kidney and pancreas (K/P) 














Age > 21 years 


25458 


89.9% 


4.8% 


4.0% 


0.4% 


0.9% 


Age < 21 years 


401 


71.1% 


4.0% 


20.7% 


3.0% 


1.2% 


Non-K/P organs 














Age > 21 years 


17642 


77.8% 


0.2% 


19.2% 


2.1% 


0.7% 


Age < 21 years 


2060 


26.7% 


0.0% 


62.8% 


9.8% 


0.6% 


Kidney and pancreas (K/P) 














Died within 1 year of transplant 


4504 


89.8% 


3.8% 


5.6% 


0.6% 


0.2% 


Died > 5 years after transplant 


12081 


88.7% 


5.8% 


4.0% 


0.4% 


1.1% 


Non-K/P organs 














Died within 1 year of transplant 


9651 


67.9% 


0.0% 


28.3% 


3.7% 


0.1% 


Died > 5 years after transplant 


3299 


80.4% 


0.6% 


14.9% 


2.3% 


1.7% 



Source: SRTR data analyses. August 2002. 



added last contribute so few additional deaths suggests 
that a satisfactory fraction of deaths is found, and finally, 
because the SSDMF and OPTN each contribute a unique 
set of deaths, it is important to avoid relying on only one or 
the other. 

The 'Analytical Approaches' article in the Annual Report 
discusses the use of the SSDMF in survival analyses. 
When deaths identified by the SSDMF are added to 
those identified by the OPTN data, we must also adjust 
the follow-up time for all patients. If information is only 
added about persons who die, then death rates will be 
overstated. The SRTR assumes that with the SSDMF data 
we know about virtually all of the deaths; a corollary of this 
approach is to assume that patients survive after trans- 
plant until the end of the study period during which we 
expect each source to capture deaths, unless we know 
otherwise. Therefore we do not censor patients at the last 
OPTN follow-up date, instead extending the follow-up 
time to the end of the study period. This adjustment 
results in almost no change in survival measures at the 
national level, even for 5- and 1 0-year survival. The lack of 
change even for these longer study periods — in which we 
have shown that many deaths are missing — suggests that 
the recipients actually followed by the transplant centers 
constitute an unbiased sample, and are similar to those 
patients who are lost to follow-up during the study period. 
However, at the transplant program level, some programs 
do show substantially different survival measures when 
the SSDMF data are added. 

Other external sources and strategies 

For measures other than mortality and graft failure, several 
additional data sources may also be incorporated with 
primary data sources for research on transplantation and 



data validation. For example, the Surveillance, Epidemi- 
ology, and End Results (SEER) program of the National 
Cancer Institute, one of the most complete sources of 
information on cancer incidence and survival in the United 
States, may be incorporated. After testing initial incorpor- 
ation of SEER data from southeast Michigan, the SRTR 
hopes to make use of SEER's highly accurate cancer 
registries both for validating the post-transplant malig- 
nancy data reported on follow-up forms to the OPTN, 
and for gaining more complete information for time peri- 
ods before the recent inception of malignancy ascertain- 
ment by the OPTN. 

In some cases, data that are useful to correlate with each 
other are not collected by the OPTN at the same time. For 
example, in order to simulate the effects of the recent 
allocation rule change for livers from an urgency status- 
based one to MELD, it is necessary to have a period of 
data collection for which we know both the MELD score 
and the urgency status for each patient. There was a short 
period during which both measures were collected, but 
doing so was voluntary. Therefore, it has been useful to 
obtain hospital laboratory data for actual candidates on the 
waiting list, in order to associate an urgency status with a 
distribution of calculated MELDs. These data have also 
allowed an earlier look at associations between waiting 
list and post-transplant outcomes than might have been 
afforded by waiting for real allocation MELDs; they also 
allow a comparison of the associations between these 
outcomes and MELD to the former, more discrete, 
urgency status system. Going back to Figure 1, these 
data augment the candidate status history file. 

Other external data sources do not necessarily require 
direct linking with primary source data in order to be 
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useful. For example, the OPTN, SRTR, and other researchers 
have investigated methods to make associations between 
0P0 practice patterns and donor procurement, consider- 
ing the suitability for transplantation of deaths in hospitals 
served by each OPO. The NCHS provides files that can 
help tabulate numbers of 'evaluable' deaths (deaths that 
provide a suitable source of organs, given cause, circum- 
stance, and location of death), as well as demographic 
data about the deceased. 

Finally, the OPTN and SRTR are together investigating the 
possibility of sampling strategies to maintain or expand 
the scope of data collection while also decreasing the 
burden of data collection on the facilities. It is possible 
that certain research may not require data to be collected 
regarding all transplant recipients, and perhaps a subset of 
patients would be selected for an extended follow-up form 
to cover these areas. 

Conclusions 

We believe that researchers interested in any aspect of 
transplantation, from donor recovery to organ allocation to 
post-transplant survival, will find this article useful. We 
have shown that a tremendous effort has been in making 
these data high-quality and well-organized for research at 
the SRTR, OPTN, and among other researchers. Further, 
we have shown that these efforts have paid off. For many 
research questions, the data submitted to the OPTN are 
complete and of high quality; for other questions, second- 
ary sources are easily integrated to improve data quality or 
expand data scope. These resources taken together pro- 



vide a rich and accurate source of information about the 
transplant process. 

Even the extensive effort of the OPTN and SRTR staff at 
ensuring high-quality and well-organized data for research 
pales in comparison to the resources devoted to data 
submission on the part of staff at transplant centers and 
OPOs. These OPTN members understand that improving 
patients' lives is an incremental process, the benefits of 
which may be long in being realized, and which often 
begins with ensuring that the information is available 
upon which to reach sound scientific conclusions. None 
of this rich source of data would be possible without 
these tireless efforts. 
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